Re: cvs commit: src/include stdlib.h

[Hiten Pandya <hmp@xxxxxxxxxxxxx>]

Limiting damage is more important sometimes than just doing the correct thing.

Please do version bumps just the way the FreeBSD people do for compensating 
with these kind of changes.  If not sure when making changes, do not hesitate 
to consult a group of fellow committers or the list for advice; being 
sensisble is more important than being elite.  Extra pair of eyes pre-commit 
always helps.

Another thing, *DO NOT* make changes to the source without understanding 
possible repercussions and having possible ways to compensate for them.

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.

Please keep these issues in mind before taking decisions that could possibly 
have The Butterfly Effect on things.

Kind regards,

			-Hiten
			Hiten Pandya
			hmp@xxxxxxxxxxxxxxxx

Jeroen Ruigrok/asmodai wrote:
> -On [20050430 16:22], Joerg Sonnenberger (joerg@xxxxxxxxxxxxxxxxx) wrote:
>
> > Sorry, but that's a stupid argument.
>
>
> Thanks for labeling it stupid.
>
>
> > Just because gmake wants to have a local (conflicting) prototype instead of
> > using the correct header should not stop us from doing the correct thing.
> > To make this even more clear, GNU make (like many GNU programs) depends on
> > the existance of errno as macro, otherwise they depend on it being int.
>
>
> 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.
>
>
> > Those are bugs. WTF do they have autoconf if they still hack around it
> > in all places?
>
>
> Ask them.
>
> 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.
>
>
> > This change does NOTHING for all programs which correctly include stdlib.h
> > and use the function defined there.
>
>
> Your change did nothing for the dependency in ports.  This is an argument
> that can be debated towards both sides of the fence.