64-bit NULL: a followup

[Harti Brandt]

On Sat, 29 Nov 2003, Bruce Evans wrote:

BE>On Fri, 28 Nov 2003, Marcel Moolenaar wrote:
BE>
BE>> Notice the "st8".  Since NULL is a pointer constant, programmers do
BE>> (implicitly) expect it to have the same width as a pointer type and
BE>> thus do not cast it to a pointer type or an integer type that has a
BE>> width larger or equal to a pointer type.
BE>
BE>FreeBSD programmers would never do that ;-), since style(9) requires
BE>casting of NULL in function args and mentions this point.  (This part
BE>of style(9) was written before everything in FreeBSD was prototyped,
BE>so the cast was required even for non-variadic functions.)

A couple of weeks ago I searched the tree for occurences of execl with
missing casts. There is still one occurence in our sources. There are
several in contrib. I have contact most authors and all of them have fixed
it (except the gdb people - no answer from the up to now). Problematic are
nvi (the maintainer said he'll fix it, but doesn't know whether there will
be another version of nvi) and bind. The bind in our tree isn't maintened
anymore by ISC and bind 9 doesn't have execv().

All that said, I think whether we change the definition or not it's always
best to contact the original authors.

BE>
BE>> So, the bottomline is that we currently do have third-party code that
BE>> fails to run on ia64 (and possibly other 64-bit platforms) due to the
BE>> fact that NULL is defined as 0.
BE>>
BE>> Since Erik thinks 0 and 0L are both perfectly good definitions for
BE>> NULL and Tony emphasizes that NULL is an integer expression, I think
BE>                                     ^^ may be
BE>> we should change the definition of NULL to 0L to improve portability
BE>> to FreeBSD/LP64. It will definitely fix known breakages on ia64.
BE>
BE>This would be bogus.  Long doesn't have the same width as `void *' on all
BE>machines.  ((void *)0) is better, but I wouldn't change it, except
BE>locally to trap errors.  __builtin_null would be better for trapping
BE>errors.

Yes. Best would be if gcc complains when applying a default promotion to
__builtin_null. But hacking gcc was a disgusting experience last time I
did it (around 2.5 or 2.6).

harti
-- 
harti brandt,
http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private
brandt at fokus.fraunhofer.de, harti at freebsd.org