Re: NULL in variadic function calls
From: Micah Cowan (micah_at_cowan.name)
Date: 10/30/03
- Next message: Andrei Voropaev: "Re: send problems linux"
- Previous message: goutaman: "analyzing core dump"
- In reply to: Jerry Feldman: "Re: NULL in variadic function calls"
- Next in thread: Goran Larsson: "Re: execl returns -1?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 29 Oct 2003 22:59:25 -0800
Jerry Feldman <gaf-noSPAM@blu.org> writes:
> On Sat, 25 Oct 2003 17:40:54 -0700
> Erik Max Francis <max@alcyone.com> wrote:
>
> > Jerry Feldman wrote:
> >
> > > It does the right thing on the 64 bit Alpha (Tru64 Unix, Linux, and
> > > NT),
> > > and it does the right thing on 64 bit HP-UX.
> > > The 0 gets promoted to a long. All function arguments are widened to
> > > 64
> > > bits. In the case or 0 (or positive ints), there is no sign
> > > extension issue.
> >
> > You're missing the point. Whether or not it happens to work properly
> > on some particular architectures with some particular compilers is
> > immaterial to the question of whether the cast is required by the
> > Standard. The Standard states that the lack of a cast results in
> > undefined behavior.
> >
> > It is true that on most modern compilers and architectures, the null
> > pointer value is all-bits-zero and ints are the same size as pointers
> > (which have the same size and representation for all types). But that
> > doesn't make the cast any less required; it just means that broken
> > code will luckily work.
> I still disagree. The wording in the standard states that the null
> pointer constant is "an integral expression with the value 0, or such an
> expression cast to type void * ... is assigned to ... a pointer of that
> type".
> The statement is vague enough such that a header file could define NULL
> to be the integer 0 and still be legal. But, if NULL is defined
> correctly, it should be defined as an integral constant as wide as a
> pointer (eg. 0L on a 64 bit system).
No. There is no need for it to be so defined, because when used
*correctly*, it would always be suitably converted first. The
fact that 0 is a null pointer constant does not mean that it's
value is a null pointer: it clearly is not. It is meant to be
used in contexts where it will be implicitly converted to a
pointer (say, via assignment, etc.). The standard is *very* clear
that actual null pointers need not be represented in the same way
that integer zero is, and in particular that it need not be
represented as all-bits zero: and in fact, all-bits zero can be a
valid pointer value, representing an actual, valid memory
location.
> By casting NULL (char *) or (void *) you are communicating to the
> compiler, exactly what NULL is rather than leaving it to the header,
No: you are communicating what a null pointer is. NULL is not
meant to represent a null pointer, but to represent the null
pointer constant. There is a difference. In most cases, it will
be implicitly converted (if necessary) to the correct type. In
the case of a variadic function, it is crucial that a cast be
performed, because the compiler will not know to convert 0 by
itself (should that be how NULL was defined), nor would it know
to convert 0L or whatever.
Please see the many, many, *many* threads on this subject at
comp.lang.c, as well as the comp.lang.c FAQ, especially:
http://www.eskimo.com/~scs/C-faq/s5.html
> thus improving portability and correctness of the code on nearly every
> platform. Void * would be proper on a standards conforming
> implementation and char * would not be incorrect in any case.
Wrong. Despite the fact that they are represented the same, the
Standard does not make an exception for char*. Though unlikely, a
particularly pedantic implementation (such as one I may write
someday) could explicitly *check* to see if you passed a char*
where a void* was expected. This is more work than its work,
unless you're goal in building an implementation was to not only
run code, but catch every conceivable error on the programmer's
part. But still, as far as the Standard is concerned, it would be
completely within its rights to do anything at all once you tried
such a thing.
-- Micah J. Cowan micah@cowan.name
- Next message: Andrei Voropaev: "Re: send problems linux"
- Previous message: goutaman: "analyzing core dump"
- In reply to: Jerry Feldman: "Re: NULL in variadic function calls"
- Next in thread: Goran Larsson: "Re: execl returns -1?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
