X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f
Date: Tue, 3 Feb 2004 09:03:39 -0500
Message-Id: <200402031403.i13E3dPA003089@envy.delorie.com>
From: DJ Delorie <dj AT delorie DOT com>
To: djgpp-workers AT delorie DOT com
In-reply-to: <Pine.OSF.4.58.0401211124440.9432@sirppi.helsinki.fi> (message
	from Esa A E Peuha on Wed, 21 Jan 2004 11:48:24 +0200 (EET))
Subject: Re: Patch for bsearch
References: <Pine DOT OSF DOT 4 DOT 58 DOT 0401201143590 DOT 29095 AT sirppi DOT helsinki DOT fi>
 <200401201626 DOT i0KGQ7d8026812 AT envy DOT delorie DOT com> <Pine DOT OSF DOT 4 DOT 58 DOT 0401211124440 DOT 9432 AT sirppi DOT helsinki DOT fi>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk


> Strict ANSI C may say so, but GNU C has sizeof(void) == 1 (and therefore
> arithmetic on void pointers works just like on char pointers).  Is there
> any reason not to use GNU extensions in the library sources?

I'd rather avoid extensions when there are ways of doing it portably,
assuming that it doesn't make the code a lot harder to read.  You
never know when GCC will become more strict (like always warning) and
we'd have a mess to clean up.

> > I'm also not a big fan of "NULL" in general, but it's OK in this case.
> > In general, NULL is *not* the same as a literal zero.
> 
> Yes, but I thought that the difference was a reason _not_ to use literal
> zero when it would be implicitly cast to a pointer.

A literal zero can always be cast to any pointer.  NULL cannot always
be cast to other types of zeros.  I've seen compilers that defined
NULL to a specific types of pointer, which caused numerous errors.
Like I said, it's OK for us in DJGPP (becuase I know DJGPP defines it
to be a literal zero anyway) but in general I don't like NULL.  There
was also a time when g++ defined NULL to __null and got it wrong for
djgpp, causing lots of problems.