I am surprised and pleased. Most discussions of this ilk I've been in
have degenerated to name-calling by this point. Thank you for doing
your part of keeping it non-acrimonious.
>> You appear to be reading the first sentence as being "a null pointer
>> constant is some implementation-defined (or undefined) thing, which
>> might be an integer constant expression with value 0, or might be
>> such an expression cast to void *, or might be something else
>> entirely".
> The standard explicitly says that "NULL" is implementation defined.
> It also says it is a null pointer constant. It does not say it must
> expand to the token "0".
True, it doesn't. But - my reading! - NULL must be a NPC, meaning it
must be 0 or (void *)0 (well, where "0" really means "integer constant
expression with value 0"; (void *)(5-3-2) is just as good). There is
no spec for which, so portable code must not depend on which. See
below for another stab at the reading of that crucial sentence of
6.3.2.3.3.
Since there is no specific specification for what happens to a NPC in a
non-pointer context such as a varargs variable argument, NULL's
expansion being an NPC is of no relevance to what you get when using
NULL in such a context: you get integer zero if it's 0 and a null
pointer-to-void if it's (void *)0. For those to appear identical to
the called function is what I called the "concealment condition" in an
earlier message - the condition under which the bug will be concealed.
What you've said upthread makes me think you think of a "null pointer
constant" as some kind of always-a-pointer-and-always-null thing.
That's not what I read the technical term "null pointer constant", as
defined in the spec, as being.
> So, I ask again - do you know of any platforms which we care about,
> where you can't pass NULL to ... and have it work as expected?
No. As I said, the bug is concealed on most common - and indeed, most
mildly uncommon - platforms. If "it runs" is your touchstone, there is
nothing left to do but add the terminators to the calls that are
missing them. I was proceeding from the premise that you'd want the
code to he _right_, not just working.
Test to a machine with NULL defined as 0 and integers smaller than
pointers in a varargs arglist - or a machine where ring addressing or
some such which makes null pointers not all-bits-0 - and watch the
fireworks. (Except for the definition-of-NULL part, something you said
upthread makes me think you already test on such hardware. Defining
NULL as the (void *)0 option in that case is a choice which is good
because it makes code work but is bad because it leads people to think
their buggy code is fine because "it works, so what's the problem?".)
>> For what it may be worth, K&Rv2 seems to be closer to my
>> interpretation than yours (page 102 says unadorned zero converts to
>> a null pointer,
> Not in something like "f += 0;" where f is type "float".
Well, no; I was being brief, rather than retyping the whole context
from the book. Here it is:
Pointers and integers are not interchangeable. Zero is the
sole exception: the constant zero may be assigned to a pointer,
and a pointer may be compared with the constant zero. The
symbolc constant NULL is often used in place of zero, as a
mnemonic to indicate more clearly that this is a special value
for a pointer.
> The above is: An A is C or D. The NPC case is: C or D is an A.
If you read it as describing a relationship between independently
defined entities, yes. But it's not "a C or a D is an A"; it's "a C or
a D is called an A", which I read (especially in context) as defining
the term A to be a collective term encompassing Cs and Ds.
> Again, that clause is in the context of conversions to pointers. If
> you're converting to pointer, "0" is a NPC. If you are not
> converting to pointer, 0 might not be a NPC.
I would say, rather, that 0 is an NPC, always, by definition of an NPC,
but that, in a non-pointer context, an NPC's NPCness is irrelevant. In
"int i = 0;" I would say that the 0 is a null pointer constant (it fits
the definition) but, because the context is not one for which anything
special happens to null pointer constants, that fact is irrelevant.
Very much like a varargs arglist, actually. :)
>>> And before we start throwing qualifications around... I'm [...]
>> Was I throwing qualifications around? I didn't think so.
> I said *before* we start throwing :-)
So, you just wanted to get in the first qualification-throw? :-)
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML [EMAIL PROTECTED]
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
