Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 21 Aug 2002 18:22:25 -0600 (MDT)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        archie@dellroad.org
Cc:        freebsd-arch@FreeBSD.ORG
Subject:   Re: NULL
Message-ID:  <20020821.182225.58446828.imp@bsdimp.com>
In-Reply-To: <200208212358.g7LNw8l08243@arch20m.dellroad.org>
References:  <20020821.173653.57449387.imp@bsdimp.com> <200208212358.g7LNw8l08243@arch20m.dellroad.org>

next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200208212358.g7LNw8l08243@arch20m.dellroad.org>
            Archie Cobbs <archie@dellroad.org> writes:
: M. Warner Losh writes:
: > : The patch makes 'make buildworld' and 'make buildkernel KERNCONF=LINT'
: > : work for me; fyi I have "NO_WERROR= YES" in /etc/make.conf.
: > : 
: > : Does anyone have an objection to this patch?
: > 
: > Yes.  I'm not sure that (void *)0 is the right thing to do.  It can
: > cause other problems and mask a different set of bugs, especially when
: > you call functions that have no prototype in scope.
: 
: Can you elaborate?
: 
: Seems like the same is true of "0".. e.g., suppose that pointers
: are larger than integers, and you call a variadic function with
: "NULL" as one of the extra parameters:
: 
: 	printf("foo=%p num=%d\n", NULL, 123);
: 
: This would get screwed with NULL=0 but work right with NULL=(void *)0.


Consider the following two files:

foo.c:

int foo(int a, int b)
{ ... }

fee.c:

int foo(void * a, int b)
{ ... }

bar.c

extern int foo();	/* old-style decl (not a prototype) */

...
	foo(NULL, 10);		/* Used to work, but now undefined */
...

Right now, bar.c + foo.c works, and bar.c + fee.c is undefined.  
With the change, we switch the two.

On x86, this doesn't matter.  Both work.  But on the alpha, we've
traded one set of working to the other working.

printf("foo = %d", NULL);

also changes in subtle ways.

So I'm not sure this is the right thing to do.  These abstract changes
seem fairly simple, but in the context of complex programs, it could
be much harder to track down.  Also, we're getting kinda late in the
current release cycle to be making changes this fundamental....

Warner


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020821.182225.58446828.imp>