asmodai     2005/04/30 01:24:48 PDT

DragonFly src repository

  Modified files:
    include              stdlib.h 
  Log:
  Back out getloadavg()'s change from int to size_t.  This breaks gmake, for
  example.  No telling what else breaks.
  Needs further investigation.
  
  Revision  Changes    Path
  1.16      +1 -1      src/include/stdlib.h


http://www.dragonflybsd.org/cvsweb/src/include/stdlib.h.diff?r1=1.15&r2=1.16&f=u
[ message continues ]

I think a matching change is needed in libc/gen/getloadavg.c, maybe?
[ message continues ]

Feck.  Yeah.  It should.

-- 
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono
Free Tibet! http://www.savetibet.org/ | http://ashemedai.deviantart.com/
http://www.tendra.org/   | http://www.in-nomine.org/
Love will draw us in, to wipe our tears away...
[ message continues ]

Sorry, but that's a stupid argument. 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.

Those are bugs. WTF do they have autoconf if they still hack around it
in all places?

This change does NOTHING for all programs which correctly include stdlib.h
and use the function defined there.

Joerg
[ message continues ]

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

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

Your change did nothing for the dependency in ports.  This is an argument
that can be debated towards both sides of the fence.

-- 
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono
Free Tibet! http://www.savetibet.org/ | http://ashemedai.deviantart.com/
http://www.tendra.org/   | http://www.in-nomine.org/
The quieter you become, the more you are able to hear...
[ message continues ]

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@dragonflybsd.org

[ message continues ]

There's no need for any version bump. The ABI didn't change and
any application NOT thinking wiser than the system continues to work.

Joerg
[ message continues ]

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)

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

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,

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
[ message continues ]

There's a project right there if people feel like coding.  Get us


True, but on the other hand, we also have to play ball by the rules set by
some of the other OSes as well.  Then again, Linux has been gratuitously
different from BSD a lot of times as well, just because Linus had an itch.

-- 
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono
Free Tibet! http://www.savetibet.org/ | http://ashemedai.deviantart.com/
http://www.tendra.org/   | http://www.in-nomine.org/
The Way that can be told is not the eternal way...
[ message continues ]