Re: cvs commit: src/include stdlib.h

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

On Sat, Apr 30, 2005 at 03:52:23PM +0100, Hiten Pandya wrote:
> Another thing, *DO NOT* make changes to the source without understanding 
> possible repercussions and having possible ways to compensate for them.

I'm trying very hard. But frankly speaking, I don't care about breaking
programs which don't play according to the rules. Sorry for not having
run a ports build cycle in between, which would have caught the (mostly)
intentional breaking of gmake, I would have fixed it immediately.

> Recently there have been quite a few build breakages, and possible runtime 
> issues raised (e.g. select(2) broken with posix threads) because the 
> changes didn't undergo careful review from the committer.

Is it still broken? Do you have a test case? I just have the normal
DNS related problems with Firefox, but the resolver is on the list of
things to work on soon.

> >Well sorry, I am merely trying to limit damage where I can.  gmake is a
> >heavy dependency for a lot of ports.  I have too little time to check
> >everything as thoroughly as I want to, and as little an excuse as it might
> >seem, I try what and where I can.  DragonFly is not the only thing I work
> >on.

Sorry, for the harsh reaction, but since this didn't introduce a big
damage (a non-compilable port is often a small damage, even if it often
used), I'd prefer a note first. I must have skipped the mail from walt,
this was nothing personal.

> >Nevertheless getloadavg() in Linux land has int as second argument, not
> >size_t.  The same goes for Solaris.  So moving it from int to size_t seemed
> >like a gratuitous change from a de-facto standard.

Well, you know that Linux still plays the off_t is 32bit game?
I want to push a common type convention into all of libc, if there isn't
an explicit standard prohibiting it. This also helps to ensure that
software is correct by making certain types of things like explicit
prototypes with some interface instead of using header files a compile
time error. I would be worried about this if it would lead to silent
errors, as long as that's not the case it's not a problem.

Joerg