a function that returns nothing?
nmk...@inreach.com
If I have a function that is supposed to return a double, is there any
way I can exit the function without returning a value? If I can' t do
that, is returning NULL the same as returning 0?
Rainer Temme
double f1(void)
{
return(some_thing);
}
you can't just return; At least this should produce a
compiler-warning/error-message.
...
return(NULL);
will return the value ((double)(NULL)) and because normaly NULL is defined
as 0 or 0L
this will be the same as return(0.0); but you should NOT make assumptions
on how
NULL is really defined (even if it is 0 on almost every system/compiler).
If you need a seperate error-indication, wouldn't it be the better way to
do it like this:
double f1(int *err_flag)
{
...
/* error */
*err_flag=1;
return(0.0);
...
/* no error */
*err_flag=0;
return(something);
}
John Winters
In article <34585577...@inreach.com>, <nmk...@inreach.com> wrote:
>If I have a function that is supposed to return a double, is there any
>way I can exit the function without returning a value?
Well, you could use longjmp, but I don't think that's what you're
looking for.
Short answer - no you can't. You'll probably need to nominate a value
(0 or -1 perhaps?) which means to your calling code "no result").
>If I can' t do
>that, is returning NULL the same as returning 0?
Possibly, but it's bad style. NULL is a macro for use in creating
null pointers. It will typically be defined in one of these two
ways:
#define NULL 0
or
#define NULL ((void *) 0)
Now if your system happens to have the former definition and you write
return NULL;
in a function which returns a double it will work *by coincidence*. On
a system with the latter definition you'll get a diagnostic, and possibly
it won't compile. On either system, it will be liable to confuse the
poor sod who comes along after you, because it appears to be trying to
return a pointer.
If you want to return the value 0 from your function, use:
return 0.0;
and nothing else.
John
--
John Winters. Wallingford, Oxon, England.
Want to buy Linux CDs cheaply in the UK? Join the Linux Buyers' Consortium.
See <http://www.polo.demon.co.uk/lbc.html>
James Youngman
>>>>> "nmk213" == nmk213 <nmk...@inreach.com> writes:
nmk213> If I have a function that is supposed to return a double, is
nmk213> there any way I can exit the function without returning a
nmk213> value?
Throw an exception.
nmk213> If I can' t do that, is returning NULL the same as
nmk213> returning 0?
No, you should return a double -- or nothing :-)
Why was this crossposted to comp.lang.c++ AND comp.lang.c? Can you
not decide what language you are working in?
Note: followups redirected since my answer is "in" C++.
Ron Natalie
> Returning NULL can be trickey depending on what operating system you
> use because null is somtimes the reset vector and in the SUN I think
> it is a location where a program could run ( ASK OTHER PEOPLE aswell )
> I am not 100% sure.
Obviously. NULL is zero. Must be zero. Can't be anything else.
Doesn't need to be anything else.
You're right though, it will get converted to zero in this
return, so it will be indistinguishable from zero.
Your options, as others have stated is to return some value
that you know can't be valid (if you're reasonably sure of
IEEE encoding, the NAN value is a possibility), otherwise
pick some value that's outside the domain of the problem.
The other options are to set a flag somewhere to indicate
an error, redesign the return something other than a double
to indicate status, or throw an exception.
John Winters
In article <345895...@sensor.com>, Ron Natalie <r...@sensor.com> wrote:
>> Returning NULL can be trickey depending on what operating system you
>> use because null is somtimes the reset vector and in the SUN I think
>> it is a location where a program could run ( ASK OTHER PEOPLE aswell )
>> I am not 100% sure.
>
>Obviously. NULL is zero. Must be zero. Can't be anything else.
It can. It can be zero cast to (void *)
>Doesn't need to be anything else.
>
>You're right though, it will get converted to zero in this
>return, so it will be indistinguishable from zero.
Not if it's the cast version.
R S Haigh
In article <3458B3...@CWA.de>, Stephan Wilms <Stepha...@CWA.de> writes:
> Rainer Temme wrote:
> >
> > If you need a seperate error-indication, wouldn't it be the better way to
> > do it like this:
> >
> > double f1(int *err_flag)
> > {
> > ...
> > /* error */
> > *err_flag=1;
> > return(0.0);
>
> do it the other way round, because this allows you to set up a uniform
> error handling concept: define *every* function as type "int" and
> *always* use the return value as an success/error indicator. If you
> have to return some values, like int his example a "double", use
> a pointer.
Moreover, if the call is
value = f1(&errflag)
then value gets clobbered even if there's an error, whereas in
errflag = f1(&value)
it can be arranged that value is left unchanged on error.
And moreover, in the first form, some policy has to be arranged
to ensure that errflag doesn't contain garbage in the event of there
not being an error.
--
Chris Engebretson
In article <34585577...@inreach.com>, nmk...@inreach.com writes:
|> If I have a function that is supposed to return a double, is there any
|> way I can exit the function without returning a value? If I can' t do
|> that, is returning NULL the same as returning 0?
[ This is the C answer. Other C++-specific strategies (i.e.,
throwing an exception, have already been mentioned. ]
If you know, for example, that 0.0 will never legitimately computed
by your function, then you can return that value as an indication of
error. The same can be said about other values (or ranges of values)
that your function should never return; if it always returns a
positive value when "operating properly", return a negative value
to indicate that some kind of error has occured. This is a common
approach and is used heavily in, for example, UNIX system calls.
double myfunc(void);
double d;
d = myfunc();
if (d < 0.0) { /* handle error .. */ }
On the other hand, the range of the return values of your function
is the entire range of doubles, then an alternate scenario is in
order. Most likely, the best strategy in this case is to pass in
a pointer to a double, and have the return value of the function
indicate a success or failure.
#define SUCCESS 0
#define FAILURE 1
int myfunc(double *val)
{
*val = (some computations);
if (everything went well)
return SUCCESS;
else return FAILURE;
}
/* ... */
double d;
if (myfunc(&d) != SUCCESS) { /* handle error .. */ }
On a personal note, I prefer the second approach over using a "flag
value" when working with a function that returns a floating-point
value. Using a *range* of flag values (i.e., negative numbers) is
a somewhat better choice, but IMHO a mechanism that unambiguously
indicates an error status is better design that makes it easier for
future maintainers to see what your code is doing. If you choose to
use flag values, be sure that you document your code clearly; your
maintainers will thank you (and you may even thank yourself a year
or two down the line.)
NULL is an implementation-defined null pointer constant that has
no relevance or use in this context.
Regards,
--
Chris Engebretson --- Hughes STX Corporation | Ph#: (605)594-6829
USGS EROS Data Center, Sioux Falls, SD 57198 | Fax: (605)594-6490
http://edcwww.cr.usgs.gov/ mailto:enge...@sg1.cr.usgs.gov
Opinions here are not those of Hughes Aircraft, STX, or the USGS.
Kaz Kylheku
In article <34585577...@inreach.com>, <nmk...@inreach.com> wrote:
>If I have a function that is supposed to return a double, is there any
>way I can exit the function without returning a value? If I can' t do
>that, is returning NULL the same as returning 0?
You can just return from the function without supplying an argument expression.
However, the behavior becomes undefined if the caller attempts to retrieve the
return value.
The NULL macro is intended to be used as a null pointer constant. It is
wrong to use it as an arithmetic type. An implementation is free to define
NULL as
#define NULL ((void *) 0)
If this is assigned to a double type, it is a type mismatch which calls for
a diagnostic message, and a possible failure to translate the program.
NULL must only be used in pointer contexts.
You can return a 0 (which has type int and will be converted to a value
0.0 of type double) or the constant 0.0. This may not be what you want,
since such a value may be in the range of the calculation normally done
by the function.
Your best bet might be to have an int return value to indicate success/failure, and return the double result via a pointer:
int myfunction(double *result, double arg);
{
if (arg < -1.0 || arg > 1.0)
return 0; /* failure */
*result = calculation();
return 1; /* success */
}
--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
-- Blair P. Houghton
Lawrence Kirby
In article <34585C...@mixed-mode.de>
ger...@mixed-mode.de "Gerald Maher" writes:
>nmk...@inreach.com wrote:
>>
>> If I have a function that is supposed to return a double, is there any
>> way I can exit the function without returning a value? If I can' t do
>> that, is returning NULL the same as returning 0?
>
>No because if you return from a function
>it is done so from the stack so the stack has to be adjusted
>you need a void function this returns nothing on the stack
In C you can always return from a function without specifying a value,
either by using a return statement without an expression or "falling off"
the end of the function. So the trivial function:
double foo(void)
{
}
is valid in C. However if you don't return a value from a function the
return value as would be seen by the caller is indeterminate which means
that it is illegal (i.e. it results in undefined behaviour) for the
caller to examine this value. So this can't be used as a mechanism to
indicate no value to the caller. It exists as a throwback to pre-ANSI
days where there was no void type and the normal way of defining a
function that didn't return a value was to create a function returning int
but not return a specific value. The caller never used the function return
value so there was no problem. On implementations that use a stack the
compiler has to ensure that the stack is tidied up properly on return
whether or not an explicit value is returned.
>Returning NULL can be trickey depending on what operating system you use
>because null is somtimes the reset vector and in the SUN I think it is a
>location where a program could run ( ASK OTHER PEOPLE aswell ) I am not
>100% sure.
When a function returns a double the only values you can return are double
values. NULL isn't a double value. There is some leeway in how an
implementation can define it, some can be converted implicitly to double,
others not. Other replies explain this in more detail.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
Harald Finster
nmk...@inreach.com wrote:
>
> If I have a function that is supposed to return a double, is there any
> way I can exit the function without returning a value? If I can' t do
> that, is returning NULL the same as returning 0?
Hi,
I suppose you want to return 'nothing' to indicate an error-state
(i.e. something went wrong inside of the function).
If you want to do this using the return-value and the expected
return type is double, you have to use a double value.
It might be possible to use one of the 'special' double values
like 'NaN' (Not a Number) or 'Infinity'.
Choose something, that gives an indication on WHAT went wrong.
(e.g 'NaN' if 'function' returns something similar to 0/0
or 'Infinity' if the funcion's result is out of range)
Returning 0 or NULL does not seem to be useful, because '0' is a valid
double-value and the caller of the function can not distinguish,
if your result is a valid '0' or an error.
In many cases a better approach is using the exception-handling
system of C++ (throw - catch).
Harald
Gerald Maher
nmk...@inreach.com wrote:
>
> If I have a function that is supposed to return a double, is there any
> way I can exit the function without returning a value? If I can' t do
> that, is returning NULL the same as returning 0?
No because if you return from a function
it is done so from the stack so the stack has to be adjusted
you need a void function this returns nothing on the stack
.
Returning NULL can be trickey depending on what operating system you use
because null is somtimes the reset vector and in the SUN I think it is a
location where a program could run ( ASK OTHER PEOPLE aswell ) I am not
100% sure.
Michael J. Fromberger
In <34585577...@inreach.com> nmk...@inreach.com writes:
> If I have a function that is supposed to return a double, is there
> any way I can exit the function without returning a value? If I
> can' t do that, is returning NULL the same as returning 0?
NULL is typically defined in one of the library header files to be a
suitable value for assignment to pointers. The commonest definition
I've seen thus far has been:
#define NULL 0L
So, while returning NULL generally amounts to returning zero, you
would do better to simply write:
return 0.0; /* for example */
...and leave NULL for contexts where a pointer is involved. I'd argue
that returning NULL when a double is expected obscures the intended
semantics.
As for exiting without returning any value, you cannot. Or, more
specifically, if you simply write:
return;
...the compiler will (read: should) complain that you declared the
function to return type double, but provided no return value
expression.
Cheers,
-M
-- . -.. .. .- . ...- .- .-.. .. ... - -.-. --- -- .--. --- ... . .-.
Michael J. Fromberger
Software Engineer, Thayer School of Engineering
Dartmouth College, Hanover, New Hampshire, USA
Fromb...@Dartmouth.EDU / st...@linguist.dartmouth.edu
--. ..- .. - .- .-. .. ... - .-.. .. -. --. ..- .. ... - -- .--- ..-.
32: Never underestimate the ability of a bureaucracy to screw things up.
Stephan Wilms
Rainer Temme wrote:
>
> If you need a seperate error-indication, wouldn't it be the better way to
> do it like this:
>
> double f1(int *err_flag)
> {
> ...
> /* error */
> *err_flag=1;
> return(0.0);
Just as a matter of preferences and style: IMO it is more elegant to
do it the other way round, because this allows you to set up a uniform
error handling concept: define *every* function as type "int" and
*always* use the return value as an success/error indicator. If you
have to return some values, like int his example a "double", use
a pointer.
Stephan
(initiator of the campaign against grumpiness in c.l.c)
Alicia Carla Longstreet
Ron Natalie wrote:
> > Returning NULL can be trickey depending on what operating system you
> > use because null is somtimes the reset vector and in the SUN I think
> > it is a location where a program could run ( ASK OTHER PEOPLE aswell )
> > I am not 100% sure.
Wrong, there is no guarentee that NULL is zero. The C standard allows
implementation to define what NULL means (usually a pointer to nowhere),
and since C++ has no standard as of yet...
> You're right though, it will get converted to zero in this
> return, so it will be indistinguishable from zero.
Really, I wouldn't stake my life on it. I wouldn't even bet my paycheck
on it.
--
Isn't it a bit unnerving that doctors call what they do "practice"?
Why do they report power outages on TV?
Why do people who know the least know it the loudest?
If vegetarians eat vegetables, what do humanitarians eat?
From the Zen of George Carlin.
=========================================
Alicia Carla Longstreet ca...@ici.net
=========================================
READ THE FAQ for more information:
C-FAQ ftp sites: ftp://ftp.eskimo.com or ftp://rtfm.mit.edu
Hypertext C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Stephan Wilms
Alicia Carla Longstreet wrote:
>
> Ron Natalie wrote:
>
> > Obviously. NULL is zero. Must be zero. Can't be anything else.
> > Doesn't need to be anything else.
>
> Wrong, there is no guarentee that NULL is zero. The C standard allows
> implementation to define what NULL means (usually a pointer to nowhere),
> and since C++ has no standard as of yet...
Hmmm, this special statement is wrong. The constants NULL is guarantied
to be numerically equivalent to the number 0 ! It's the compiler who
*must* do some internal (hidden) translation if 0 is assigned to a
pointer and a different 0 pointer representation is required by the
prozessor. Please read the FAQ sections quoted below for a good and
verbose explanation.
> > You're right though, it will get converted to zero in this
> > return, so it will be indistinguishable from zero.
>
> Really, I wouldn't stake my life on it. I wouldn't even bet my paycheck
> on it.
There's a lot of good info concerning this subject in the c.l.c FAQ:
5.1: What is this infamous null pointer, anyway?
5.3: Is the abbreviated pointer comparison "if(p)" to test for non-
null pointers valid? What if the internal representation for
null pointers is nonzero?
5.5: How should NULL be defined on a machine which uses a nonzero bit
pattern as the internal representation of a null pointer?
5.9: If NULL and 0 are equivalent as null pointer constants, which
should I use?
5.10: But wouldn't it be better to use NULL (rather than 0), in case
the value of NULL changes, perhaps on a machine with nonzero
internal null pointers?
5.13: This is strange. NULL is guaranteed to be 0, but the null
pointer is not?
5.14: Why is there so much confusion surrounding null pointers? Why
do these questions come up so often?
5.17: Seriously, have any actual machines really used nonzero null
pointers, or different representations for pointers to different
types?
You can get the FAQ at http://www.eskimo.com/~scs/C-faq/top.html or
at ftp://rtfm.mit.edu/pub/usenet/comp.lang.c/C-FAQ-list and it gets
posted to this newsgroup and to news.answers regularly (at the
beginning of each month).
Dik T. Winter
In article <3458B3...@CWA.de> Stepha...@CWA.de writes:
> Just as a matter of preferences and style: IMO it is more elegant to
> do it the other way round, because this allows you to set up a uniform
> error handling concept: define *every* function as type "int" and
> *always* use the return value as an success/error indicator.
This is too strong. But I agree, if there is the possibility of a
function failing that should be reflected in the return code, not
through some, possibly obscure, parameter. It *is* a major event!
However, if there is the possibility to return failure as an out-of-band
signal in the standard return type, there is nothing wrong with that.
Witness the *malloc family. The problem with floating point returns
(as was the question) is that you can not rely on an out-of-band
signal being available. IEEE has it (NaN, as some poster remarked,
but it is not easy to get it in C), other floating point formats do
*not* have an out-of-band signal. So, when you're writing a function
returning a floating point value that has the possibility to fail,
Stephan's advise is pretty good.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Chris Engebretson
|> Wrong, there is no guarentee that NULL is zero. The C standard allows
|> implementation to define what NULL means (usually a pointer to nowhere),
|> and since C++ has no standard as of yet...
No;
char *ptr = 0;
guarantees that ptr is initialized to a null pointer. The NULL macro
must expand to an integral constant of zero (possibly cast to (void *)
at the implementor's discretion.) What you are referring to is the
fact that the language does not require an implementation's "physical
representation" of a null pointer to be zero.
However, this aside, C programs must still use zero (and consequently
NULL must as well); it is the job of the implementation to handle the
translation to the appropriate value whenever it encounters a zero in
a pointer context.
In other words, regardless of internal representation,
#define NULL 1
is in violation of what the standard says of null pointer constants
("An integral constant expression with the value 0, or such an
expression cast to type void *, is called a null pointer constant.")
However, arbitrarily silly examples such as
#define NULL (3 - 3)
#define NULL ((void *) 2["m\0\0"])
are legal (however unlikely.)
jawalker com
On Fri, 31 Oct 1997 12:34:02 +0100, Stephan Wilms
<Stepha...@CWA.de> wrote:
>Alicia Carla Longstreet wrote:
>>
>> Ron Natalie wrote:
>>
>> > Obviously. NULL is zero. Must be zero. Can't be anything else.
>> > Doesn't need to be anything else.
>>
>> Wrong, there is no guarentee that NULL is zero. The C standard allows
>> implementation to define what NULL means (usually a pointer to nowhere),
>> and since C++ has no standard as of yet...
>
>Hmmm, this special statement is wrong. The constants NULL is guarantied
>to be numerically equivalent to the number 0 ! It's the compiler who
>*must* do some internal (hidden) translation if 0 is assigned to a
>pointer and a different 0 pointer representation is required by the
>prozessor. Please read the FAQ sections quoted below for a good and
>verbose explanation.
>
>> > You're right though, it will get converted to zero in this
>> > return, so it will be indistinguishable from zero.
>>
>> Really, I wouldn't stake my life on it. I wouldn't even bet my paycheck
>> on it.
>
>There's a lot of good info concerning this subject in the c.l.c FAQ:
>
[&<]
The irony is that this self same FAQ is referenced in Ms. Longstreet's
sig. Hmm.
Jack
>
>You can get the FAQ at http://www.eskimo.com/~scs/C-faq/top.html or
>at ftp://rtfm.mit.edu/pub/usenet/comp.lang.c/C-FAQ-list and it gets
>posted to this newsgroup and to news.answers regularly (at the
>beginning of each month).
>
>Stephan
>(initiator of the campaign against grumpiness in c.l.c)
My address is corrupted to reduce spam. If you can't
figure out my true address from the corrupted one I
don't want to receive email from you anyway.
SPAM food --
aori...@oiasurowue.com
Andrew Koenig
> Wrong, there is no guarentee that NULL is zero. The C standard allows
> implementation to define what NULL means (usually a pointer to nowhere),
> and since C++ has no standard as of yet...
Nonsense. For example:
#include <stdio.h>
#include <stddef.h>
int main()
{
int *p = NULL;
if (p == 0)
printf("NULL is zero\n");
else
printf("NULL is not zero\n");
return 0;
}
I believe that this is a strictly conforming C program, and that every
C implementation is required to print
NULL is zero
when executing it. I further believe that when the C++ standard is
complete, that this program will be a well-formed C++ program, and
will have the same effect when executed.
--
--Andrew Koenig
a...@research.att.com
http://www.research.att.com/info/ark
Morris M. Keesan
[comp.lang.c++ deleted from Newsgroups list, because I'm discussing
standard C, which has no useful relationship to C++ in this context]
On Fri, 31 Oct 1997 12:34:02 +0100, Stephan Wilms <Stepha...@CWA.de>
wrote:
>Alicia Carla Longstreet wrote:
>>
>> Ron Natalie wrote:
>>
>> > Obviously. NULL is zero. Must be zero. Can't be anything else.
>> > Doesn't need to be anything else.
>>
>> Wrong, there is no guarentee that NULL is zero. The C standard allows
>> implementation to define what NULL means (usually a pointer to nowhere),
>> and since C++ has no standard as of yet...
>
>Hmmm, this special statement is wrong. The constants NULL is guarantied
>to be numerically equivalent to the number 0 ! It's the compiler who
>*must* do some internal (hidden) translation if 0 is assigned to a
>pointer and a different 0 pointer representation is required by the
>prozessor.
I can't find anything anything in the standard to support Stephan's
claim. In fact, I can't find any wording about "numerical equivalence"
anywhere in the standard, or any definition of what it might mean. What
the standard says is that an integral constant expression with the
value 0, or such an expression cast to type (void *), is a null pointer
constant; that NULL must be defined as a null pointer constant; and that
null pointer constants may be converted to any pointer type, and
assigned to and compared with other pointers. Pointers may not be
compared with arithmetic expressions [6.3.9](the expression ptr == 0 is
NOT comparing ptr with the integer zero -- it's comparing ptr to a "null
pointer constant"). Pointers may be converted to and from integers, but
the results are implementation-defined [6.3.4], so there's explicitly no
guarantee that a non-constant zero-valued integer expression, when cast
to a pointer type, will compare equal to a null pointer, nor any
guarantee that a null pointer cast to an integer type will compare equal
to zero.
Researching this in the standard while composing this reply leads me to
the conclusion, which I've never thought about before, that
char *p = 0;
p == 0; /* must be true */
p == (char *)0; /* must be true */
(int)p == 0; /* may be true or false (implementation-defined) */
therefore
(p == (char *)0) == ((int)p == 0); /* implentation-defined */
--
Morris M. Keesan -- mke...@kenan.com
Kenan Systems Corporation
Peter Seebach
In article <EIxFJ...@igsrsparc2.er.usgs.gov>,
Chris Engebretson <enge...@sg1.cr.usgs.gov> wrote:
>("An integral constant expression with the value 0, or such an
>expression cast to type void *, is called a null pointer constant.")
>However, arbitrarily silly examples such as
>#define NULL (3 - 3)
>#define NULL ((void *) 2["m\0\0"])
>are legal (however unlikely.)
Legal, yes, but the second isn't valid C. Or, at least, it's not
a correct definition for NULL.
Subscript operators can't occur in a constant expression.
-s
--
se...@plethora.net -- Speaking for myself. No spam please.
Copyright 1997. All rights reserved. This was not written by my cat.
C/Unix wizard - send mail for help! -- <URL:http://www.plethora.net/~seebs>
<URL:http://www.plethora.net/> - More Net, Less Spam!
Chris Engebretson
|> In article <EIxFJ...@igsrsparc2.er.usgs.gov>,
|> Chris Engebretson <enge...@sg1.cr.usgs.gov> wrote:
|>
|> >However, arbitrarily silly examples such as
|>
|> >#define NULL (3 - 3)
|> >#define NULL ((void *) 2["m\0\0"])
|>
|> >are legal (however unlikely.)
|>
|> Legal, yes, but the second isn't valid C. Or, at least, it's not
|> a correct definition for NULL.
|>
|> Subscript operators can't occur in a constant expression.
Quite so; thanks for pointing this out. Actually, if memory serves,
you alerted me to this a year or so ago regarding the very same
issue (silly definitions of NULL)!
History really *does* repeat itself.
Peter Seebach
In article <EIxrv...@research.att.com>,
>> implementation to define what NULL means (usually a pointer to nowhere),
>> and since C++ has no standard as of yet...
>Nonsense. For example:
Actually, I hate to say it, but she's right.
It is guaranteed that 0 is a null pointer constant; it is not guaranteed
that a null pointer is 0.
> #include <stdio.h>
> #include <stddef.h>
Hmph. This is redundant; <stdio.h> also defines NULL. :)
> int main()
> {
> int *p = NULL;
> if (p == 0)
> printf("NULL is zero\n");
> else
> printf("NULL is not zero\n");
> return 0;
> }
>I believe that this is a strictly conforming C program, and that every
>C implementation is required to print
> NULL is zero
>when executing it. I further believe that when the C++ standard is
>complete, that this program will be a well-formed C++ program, and
>will have the same effect when executed.
I can't speak for the C++ standard, but you are correct.
However, this is *NOT* because, after the initialization, "p is zero",
but because, when compared to p, 0 becomes a null pointer.
In other words, C does *NOT* require "NULL is zero" from the following:
#include <stdio.h>
int main(void) {
int *p = 0;
int i = 0;
if ((int) p == 0)
printf("NULL is zero.\n");
if (0 == (int *) i)
printf("NULL is zero.\n");
return 0;
}
In fact, it doesn't even require "NULL is zero.\n". :) The first
is not guaranteed because we make no requirements on what you get
when you convert a pointer to an integer. (Indeed, we make no
requirement that you *can*.) The second is not guaranteed because i
is not a null pointer constant, but rather, a plain old integer, and
converting an integer-which-is-not-a-null-pointer-constant to a
pointer follows an implementation defined rule which is not required
to special-case 0.
(After i is converted to a pointer, the pointer and the null pointer
constant on the LHS of the == are compared, with the NPC turning
instantly into a null pointer to int, and compared...)
-s
p.s.: Most of the material here is not because Andrew Koenig won't
understand it, but so that someone who *doesn't* have his background
will be able to pick up on the point being debated.
Jack Klein
Stephan Wilms <Stepha...@CWA.de> wrote in article
<3459C2...@CWA.de>...
> Alicia Carla Longstreet wrote:
> >
> > Ron Natalie wrote:
> >
> > > Obviously. NULL is zero. Must be zero. Can't be
anything else.
> > > Doesn't need to be anything else.
> >
standard allows
> > implementation to define what NULL means (usually a pointer
to nowhere),
> > and since C++ has no standard as of yet...
>
guarantied
> to be numerically equivalent to the number 0 ! It's the
compiler who
> *must* do some internal (hidden) translation if 0 is assigned
to a
> pointer and a different 0 pointer representation is required
by the
good and
> verbose explanation.
Sorry Stephan, you are incorrect. According to the standard:
================================================
7.1.6 Common definitions <stddef.h>
[snip]
The macros are
NULL
which expands to an implementation-defined null pointer
constant;
================================================
The standard states that the compiler must recognize the
assignment of a constant 0 to a pointer, and translate this into
code actually setting the pointer to the binary pattern of a
NULL pointer. It must do the same thing with comparisons, i.e.,
if (!ptr).
But it does not require at all that NULL be defined as 0 or
(void *)0. On a machine with a representation of NULL pointers
that is not all bits 0, the macro NULL could be defined as that
actual representation.
NULL is only guaranteed to be equivalent to 0 in pointer
comparisons and tests for NULL pointers.
Jack
Jack Klein
Chris Engebretson <enge...@sg1.cr.usgs.gov> wrote in article
<EIxFJ...@igsrsparc2.er.usgs.gov>...
standard allows
> |> implementation to define what NULL means (usually a pointer
to nowhere),
> |> and since C++ has no standard as of yet...
>
>
> char *ptr = 0;
>
> guarantees that ptr is initialized to a null pointer. The
NULL macro
> must expand to an integral constant of zero (possibly cast to
(void *)
> at the implementor's discretion.) What you are referring to
is the
> fact that the language does not require an implementation's
"physical
> representation" of a null pointer to be zero.
>
> However, this aside, C programs must still use zero (and
consequently
> NULL must as well); it is the job of the implementation to
handle the
> translation to the appropriate value whenever it encounters a
zero in
> a pointer context.
>
> In other words, regardless of internal representation,
>
> #define NULL 1
>
> is in violation of what the standard says of null pointer
constants
> expression cast to type void *, is called a null pointer
constant.")
>
> However, arbitrarily silly examples such as
>
> #define NULL (3 - 3)
> #define NULL ((void *) 2["m\0\0"])
>
> are legal (however unlikely.)
>
> Regards,
>
> --
> Chris Engebretson --- Hughes STX Corporation | Ph#:
(605)594-6829
No Chris, Alicia is absolutely 100% correct. Here is a direct
quote from the standard:
================================================
7.1.6 Common definitions <stddef.h>
[snip]
The macros are
NULL
which expands to an implementation-defined null pointer
constant;
================================================
The standard says that in pointer context, the compiler must
treat an integer constant expression which evaluates to 0 the as
a null pointer constant, and set or test the pointer against
whatever internal value it uses for an actual null pointer
constant.
The standard does not say that 0 must be the actual binary
representation of the null pointer constant, and in fact on some
implementations it is not. Nor does the standard say that the
macro NULL must be defined as 0 or 0L or (void *)0, as quoted
above.
Jack
Douglas A. Gwyn
In article <EJ04z...@igsrsparc2.er.usgs.gov>,
enge...@sg1.cr.usgs.gov (Chris Engebretson) wrote:
> "An integral constant expression with the value 0, or such an
> expression cast to type void *, is called a null pointer constant."
Yes, that's at the source-code level.
>Any translation between zero and the null pointer constant proper is
>done behind the scenes by the implementation, and is completely
>transparent to user programs.
The actual representation of a null pointer doesn't have to consist
of all zero bits, which has the practical consequence that calloc()
does not necessarily properly initialize the allocated storage for
interpretation as containing null pointer constants (although any
integer types in calloc()ed storage *are* properly initialized to
zero values, as a consequence of the requirement that a pure binary
numeration system be used for representation of integer types).
Ulric Eriksson
In article <3459C2...@CWA.de>, Stephan Wilms <Stepha...@CWA.de> wrote:
>Alicia Carla Longstreet wrote:
>>
>> Ron Natalie wrote:
>>
>> > Obviously. NULL is zero. Must be zero. Can't be anything else.
>> > Doesn't need to be anything else.
>>
>> implementation to define what NULL means (usually a pointer to nowhere),
>> and since C++ has no standard as of yet...
>
>to be numerically equivalent to the number 0 ! It's the compiler who
>*must* do some internal (hidden) translation if 0 is assigned to a
>pointer and a different 0 pointer representation is required by the
>prozessor. Please read the FAQ sections quoted below for a good and
>verbose explanation.
One case where the actual bit representation of null pointers
matters is when memory is allocated with calloc. Something like
char **p = calloc(10, sizeof(char *));
is incorrect if the idea was to get 10 null pointers. The problem
is that it is correct C code and happens to work on most systems,
so it has a good chance to go unspotted.
So while NULL is guaranteed to be zero, the bit pattern isn't.
Question 7.31 in the FAQ, if anyone cares.
Ulric
--
I proactively leverage my synergies.
Andrew Koenig
> It is guaranteed that 0 is a null pointer constant; it is not guaranteed
> that a null pointer is 0.
That depends on what you mean by `is 0.' I didn't say anything about
its implementation, remember.
> In other words, C does *NOT* require "NULL is zero" from the following:
> #include <stdio.h>
> int main(void) {
> int *p = 0;
> int i = 0;
> if ((int) p == 0)
> printf("NULL is zero.\n");
> if (0 == (int *) i)
> printf("NULL is zero.\n");
> return 0;
> }
> In fact, it doesn't even require "NULL is zero.\n". :) The first
> is not guaranteed because we make no requirements on what you get
> when you convert a pointer to an integer. (Indeed, we make no
> requirement that you *can*.) The second is not guaranteed because i
> is not a null pointer constant, but rather, a plain old integer, and
> converting an integer-which-is-not-a-null-pointer-constant to a
> pointer follows an implementation defined rule which is not required
> to special-case 0.
Yes indeed.
Zero has an odd kind of special status in C (and C++). And it is precisely
because of that special status that I think it makes sense to say
that a pointer `is zero' independently of whether the implementation
may choose to represent it as a collection of bits that are all zero.
The same is true of floating-point numbers, incidentally: After
double d = 0;
there is no guarantee that d is represented by a collection of zero-valued bits.
Chris Engebretson
Jack Klein wrote:
> > In other words, regardless of internal representation,
> >
> > #define NULL 1
> >
> > is in violation of what the standard says of null pointer constants
> > constants ("An integral constant expression with the value 0, or such an
> > expression cast to type void *, is called a null pointer constant.")
> >
> > However, arbitrarily silly examples such as
> >
> > #define NULL (3 - 3)
> > #define NULL ((void *) 2["m\0\0"])
As seebs noted, the second example that I gave is not applicable.
> > are legal (however unlikely.)
> No Chris, Alicia is absolutely 100% correct.
I fear that she is not.
> Here is a direct quote from the standard:
Unfortunately, it's not the applicable part of the standard in that
it does not explain what a null pointer constant actually is.
[ snip NULL description from stddef.h ]
> The standard says that in pointer context, the compiler must
> treat an integer constant expression which evaluates to 0 the as
> a null pointer constant, and set or test the pointer against
> whatever internal value it uses for an actual null pointer
> constant.
Quite so.
> The standard does not say that 0 must be the actual binary
> representation of the null pointer constant, and in fact on some
> implementations it is not. Nor does the standard say that the
> macro NULL must be defined as 0 or 0L or (void *)0, as quoted
> above.
It does, however, state:
"An integral constant expression with the value 0, or such an
expression cast to type void *, is called a null pointer constant."
Cutting and pasting is very easy in X; in case you're wondering where
I pasted the above quote from, it was from my original post that you
replied to. :-) Yes, the standard does not mandate an "all-bits zero"
null pointer constant at the machine level, but that distinction has
no effect on C programs or the definition of NULL. It must expand to
a constant integral expression with the value zero, possibly cast to
(void *) at the discretion of the implementor.
Any translation between zero and the null pointer constant proper is
done behind the scenes by the implementation, and is completely
transparent to user programs.
Regards,
Douglas A. Gwyn
In article <345895...@sensor.com>,
>return, so it will be indistinguishable from zero.
No, the NULL macro can be implemented as (void*)0, which would
not be automatically converted to double (it would be an error).
Chris Engebretson
In article <63hab4$k...@dfw-ixnews9.ix.netcom.com>, Douglas A. Gwyn
<gw...@ix.netcom.com> writes:
|> In article <EJ04z...@igsrsparc2.er.usgs.gov>,
|> enge...@sg1.cr.usgs.gov (Chris Engebretson) wrote:
|>
|> > "An integral constant expression with the value 0, or such an
|> > expression cast to type void *, is called a null pointer constant."
|>
|> Yes, that's at the source-code level.
Which is, of course, what is discussed in comp.lang.c.
|> >Any translation between zero and the null pointer constant proper is
|> >done behind the scenes by the implementation, and is completely
|> >transparent to user programs.
|>
|> The actual representation of a null pointer doesn't have to consist
|> of all zero bits ..
This is exactly what I said; I wonder where the ambiguity arises! :-)
|> which has the practical consequence that calloc()
|> does not necessarily properly initialize the allocated storage for
|> interpretation as containing null pointer constants (although any
|> integer types in calloc()ed storage *are* properly initialized to
|> zero values, as a consequence of the requirement that a pure binary
|> numeration system be used for representation of integer types).
Quite so; for the sake of completeness it should also be noted that
the same "calloc() lack of guarantee" that exists for pointer types
also exists for floating-point types.
Regards,
--
Chris Engebretson --- Hughes STX Corporation | Ph#: (605)594-6829
USGS EROS Data Center, Sioux Falls, SD 57198 | Fax: (605)594-6490
Landsat 7 IAS Engineering Team - http://ltpwww.gsfc.nasa.gov/IAS/
Steve Summit
In article <01bce682$9b14cd60$0977420c@default>, "Jack Klein"
<jack...@worldnet.att.net> writes:
> Stephan Wilms <Stepha...@CWA.de> wrote in article
> <3459C2...@CWA.de>...
>>> Ron Natalie wrote:
>>>> Obviously. NULL is zero. Must be zero. Can't be anything else.
>>>
>>
>> Hmmm, this special statement is wrong. The constants NULL is guarantied
>> to be numerically equivalent to the number 0 ! It's the compiler who
>> *must* do some internal (hidden) translation if 0 is assigned to a
>> pointer and a different 0 pointer representation is required by the
>> prozessor.
>
>
> The macros are
> NULL
> which expands to an implementation-defined null pointer
> constant;
>
> assignment of a constant 0 to a pointer, and translate this into
> code actually setting the pointer to the binary pattern of a
> But it does not require at all that NULL be defined as 0 or
> (void *)0. On a machine with a representation of NULL pointers
> that is not all bits 0, the macro NULL could be defined as that
> actual representation.
Ahh, the null pointer wars are back! Haven't seen these in a
good long time.
The passage in the Standard which Jack cites is, by its inclusion
of those two words "implementation-defined", tremendously
misleading. The implementation gets to choose which form of null
pointer constant it uses in its definition of the NULL macro,
whether 0, 0L, or some other form of 0, and whether cast to
(void *). But the compiler is still bound by the definition of
null pointer constant in section 3.2.2.3/6.2.2.3:
An integral constant expression with the value 0,
or such an expression cast to type void *, is called
a null pointer constant.
This is *the* definition of a null pointer constant; there aren't
any others. So while it might work, in a particular environment,
for a compiler's copy of <stddef.h> to contain something like
#define NULL 06000
, and while a conforming program might not be able to tell the
difference, such a definition would clearly be contrary to the
requirements of the Standard. (Furthermore, the hypothetical
non-0 definition is unnecessary and insufficient, as the
programmer is still allowed to write his own null pointer
constants, without using the NULL macro.)
Steve Summit
s...@eskimo.com
Alicia Carla Longstreet
Andrew Koenig wrote:
Getting back to the original
double my_value;
my_value = NULL;
There is no guarentee that my_value now contains zero. NULL is created
as a test value and assignement value for pointers, and for a lot of
reasons unrelated to the fact that it is not guarenteed to be equal to
(double)0, it is a very foolish thing to do. I, for one, would not want
to have to maintain a sizeable application written by a programemr who
had a tendency to use the above assignment.
If I am wrong then the following should be portable to any
implementation, and will always return EXIT_SUCCESS:
#include <stdlib.h>
int main( void ) {
double x, y;
y = (double)0.0;
x = NULL;
if( y == x ) return (EXIT_SUCCESS);
return (EXIT_FAILURE);
}
Is there an implementation where this will return EXIT_FAILURE?
Peter Seebach
In article <EJ1L7...@research.att.com>,
Andrew Koenig <a...@research.att.com> wrote:
>In article <63do1d$qpl$3...@darla.visi.com> se...@plethora.net (Peter
>> It is guaranteed that 0 is a null pointer constant; it is not guaranteed
>> that a null pointer is 0.
>That depends on what you mean by `is 0.' I didn't say anything about
>its implementation, remember.
Right. What I mean by 'is 0' would be "if I convert this to int, will
I get 0?"
>Zero has an odd kind of special status in C (and C++). And it is precisely
>because of that special status that I think it makes sense to say
>that a pointer `is zero' independently of whether the implementation
>may choose to represent it as a collection of bits that are all zero.
>The same is true of floating-point numbers, incidentally: After
> double d = 0;
>there is no guarantee that d is represented by a collection of zero-valued
>bits.
Yes, but there *is* a guarantee that
(int) d == 0
whereas, after
int *p = 0;
there is *not* a guarantee that
(int) p == 0
(Actually, I'm not *sure* the first is guaranteed, that could be a
quality of implementation issue. C89's floating point is not very
aggressively specified.)
-s
Gabor
>
>> > It is guaranteed that 0 is a null pointer constant; it is not guaranteed
>> > that a null pointer is 0.
>
>> That depends on what you mean by `is 0.' I didn't say anything about
>> its implementation, remember.
>
>> > #include <stdio.h>
>> > int main(void) {
>> > int *p = 0;
>> > int i = 0;
>> > if ((int) p == 0)
>> > printf("NULL is zero.\n");
>> > if (0 == (int *) i)
>> > printf("NULL is zero.\n");
>> > return 0;
>> > }
>
>> > In fact, it doesn't even require "NULL is zero.\n". :) The first
>> > is not guaranteed because we make no requirements on what you get
>> > when you convert a pointer to an integer. (Indeed, we make no
>> > requirement that you *can*.) The second is not guaranteed because i
>> > is not a null pointer constant, but rather, a plain old integer, and
>> > converting an integer-which-is-not-a-null-pointer-constant to a
>> > pointer follows an implementation defined rule which is not required
>> > to special-case 0.
>
>> Yes indeed.
>
>> because of that special status that I think it makes sense to say
>> that a pointer `is zero' independently of whether the implementation
>> may choose to represent it as a collection of bits that are all zero.
>
>> The same is true of floating-point numbers, incidentally: After
>
>> double d = 0;
>
>> there is no guarantee that d is represented by a collection of zero-valued bits.
>
>
> double my_value;
>
> my_value = NULL;
>
>There is no guarentee that my_value now contains zero. NULL is created
>as a test value and assignement value for pointers, and for a lot of
>reasons unrelated to the fact that it is not guarenteed to be equal to
>(double)0, it is a very foolish thing to do. I, for one, would not want
>to have to maintain a sizeable application written by a programemr who
>had a tendency to use the above assignment.
>
>If I am wrong then the following should be portable to any
>implementation, and will always return EXIT_SUCCESS:
>
>#include <stdlib.h>
>int main( void ) {
> double x, y;
> y = (double)0.0;
> x = NULL;
> if( y == x ) return (EXIT_SUCCESS);
> return (EXIT_FAILURE);
>}
>
>Is there an implementation where this will return EXIT_FAILURE?
NULL could be defined as (void*)0 in an implementation in which case
the above wouldn't even compile. If NULL were defined to be plain 0
then I would reckon it would work in all implementations but I am no
language lawyer.
gabor.
--
[End of diatribe. We now return you to your regularly scheduled
programming...]
-- Larry Wall in Configure from the perl distribution
mha...@gov.on.ca he, he, he
Paul Black
enge...@sg1.cr.usgs.gov (Chris Engebretson) wrote:
> As has been noted several
> times elsewhere in this thread, NULL may be defined as ((void *) 0)
Not for C++.
Paul
Chris Engebretson
|> Getting back to the original
|>
|> double my_value;
|>
|> my_value = NULL;
|>
|> There is no guarentee that my_value now contains zero. NULL is created
|> as a test value and assignement value for pointers, and for a lot of
|> reasons unrelated to the fact that it is not guarenteed to be equal to
|> (double)0,
Indeed it isn't; NULL is not even *allowed* to be defined as
((double) 0).
|> it is a very foolish thing to do. I, for one, would not want
|> to have to maintain a sizeable application written by a programemr who
|> had a tendency to use the above assignment.
|>
|> If I am wrong then the following should be portable to any
|> implementation, and will always return EXIT_SUCCESS:
|>
|> #include <stdlib.h>
|> int main( void ) {
|> double x, y;
|> y = (double)0.0;
|> x = NULL;
|> if( y == x ) return (EXIT_SUCCESS);
|> return (EXIT_FAILURE);
|> }
|>
|> Is there an implementation where this will return EXIT_FAILURE?
This is not even guaranteed to compile. As has been noted several
times elsewhere in this thread, NULL may be defined as ((void *) 0)
in which case the assignment "x = NULL;" is invalid.
Regards,
--
Chris Engebretson --- Hughes STX Corporation | Ph#: (605)594-6829
USGS EROS Data Center, Sioux Falls, SD 57198 | Fax: (605)594-6490
jim
> When a function returns a double the only values you can return are double
> values. NULL isn't a double value. There is some leeway in how an
> implementation can define it, some can be converted implicitly to double,
> others not. Other replies explain this in more detail.
... or at least, argue about it at great length.
jim
--
j.ca...@physiology.ucl.ac.uk | http://www.physiol.ucl.ac.uk/~jcameron/
-This calls for a very special blend of psychology and extreme violence.
Alicia Carla Longstreet
Gabor wrote:
>
> Alicia Carla Longstreet wrote:
> >Getting back to the original
> > double my_value;
> > my_value = NULL;
> >There is no guarentee that my_value now contains zero. NULL is created
> >as a test value and assignement value for pointers, and for a lot of
> >reasons unrelated to the fact that it is not guarenteed to be equal to
> >(double)0, it is a very foolish thing to do. I, for one, would not want
> >to have to maintain a sizeable application written by a programmer who
> >had a tendency to use the above assignment.
> >If I am wrong then the following should be portable to any
> >implementation, and will always return EXIT_SUCCESS:
> >#include <stdlib.h>
> >int main( void ) {
> > double x, y;
> > y = (double)0.0;
> > x = NULL;
> > if( y == x ) return (EXIT_SUCCESS);
> > return (EXIT_FAILURE);
> >}
> >Is there an implementation where this will return EXIT_FAILURE?
> NULL could be defined as (void*)0 in an implementation in which case
> the above wouldn't even compile. If NULL were defined to be plain 0
> then I would reckon it would work in all implementations but I am no
> language lawyer.
NULL can be defined as 0, 0L, or (void *)0 (at least it has to behave as
if it were one of these). Asigning any *one* of them to a double is a
poor idea.
Kaz Kylheku
In article <63d7cb$e4o$1...@darla.visi.com>,
Peter Seebach <se...@plethora.net> wrote:
>In article <EIxFJ...@igsrsparc2.er.usgs.gov>,
>Chris Engebretson <enge...@sg1.cr.usgs.gov> wrote:
>
>>However, arbitrarily silly examples such as
>
>>#define NULL (3 - 3)
>>#define NULL ((void *) 2["m\0\0"])
>
>
>Legal, yes, but the second isn't valid C. Or, at least, it's not
>a correct definition for NULL.
>
>Subscript operators can't occur in a constant expression.
That's right. The zero that is being cast in the second example is not
an integral constant zero. Thus, it is converted to a void * in an
implementation defined manner, most likely in a way that is not
surprising to a programmer who understands the addressing structure
of the execution environment. :)
It's possible that an implementation use an address other than its zero
address for representing a null pointer, yet the above cast might
produce a pointer which represents the zero address, and therefore
is anything but null.
--
"In My Egotistical Opinion, most people's C programs should be
indented six feet downward and covered with dirt."
-- Blair P. Houghton
Andrew Koenig
> >> It is guaranteed that 0 is a null pointer constant; it is not guaranteed
> >> that a null pointer is 0.
> >That depends on what you mean by `is 0.' I didn't say anything about
> >its implementation, remember.
> Right. What I mean by 'is 0' would be "if I convert this to int, will
> I get 0?"
But no C implementation is required to permit you to convert a
pointer to int at all! So if you choose that definition, you
may find it meaningless on some implementations.
Not only that, but that definition doesn't work real well for
floating-point numbers either, because if d is a double and
(int)d == 0, most implementations will merely tell you that that
implies that (-1.0 < d) && (d < 1.0).
I'm skeptical that when you say `is 0,' you really intend
to use a definition that would result in being ablt to say
`0.4 is 0.'
For that matter, the definition doesn't even work for all
integral types -- at least not on implementations where long
has more precision than int -- because on such implementations
there will be plenty of unsigned long values that, when converted
to int, will legitimately yield zero.
I submit, therefore, that when most C programmers say `x is zero'
they do *not* mean `(int) x == 0' but rather mean `x == 0' or,
equivalently (I think), `!x'.
Now, I do completely agree with you that a pointer (or, for that
matter, of a floating-point value) that is 0 according to what I think
is the commonly accepted meaning may nevertheless have nonzero bits
in it. I don't think that was ever in dispute.
Peter Seebach
In article <EJ4Iu...@research.att.com>,
Andrew Koenig <a...@research.att.com> wrote:
>In article <63jhes$iqf$4...@darla.visi.com> se...@plethora.net (Peter
>Seebach) writes:
>> Right. What I mean by 'is 0' would be "if I convert this to int, will
>> I get 0?"
>But no C implementation is required to permit you to convert a
>pointer to int at all! So if you choose that definition, you
>may find it meaningless on some implementations.
True. (I can't recall whether intptr_t is optional or not...)
>Not only that, but that definition doesn't work real well for
>floating-point numbers either, because if d is a double and
>(int)d == 0, most implementations will merely tell you that that
>implies that (-1.0 < d) && (d < 1.0).
True.
>I'm skeptical that when you say `is 0,' you really intend
>to use a definition that would result in being ablt to say
>`0.4 is 0.'
Well, it is, as an integer. :) However, I think you have
a significant point.
>I submit, therefore, that when most C programmers say `x is zero'
>they do *not* mean `(int) x == 0' but rather mean `x == 0' or,
>equivalently (I think), `!x'.
Hmm.
Okay, I'll accept this definition as improved, and in that case, yes,
null pointers are zero.
>Now, I do completely agree with you that a pointer (or, for that
>matter, of a floating-point value) that is 0 according to what I think
>is the commonly accepted meaning may nevertheless have nonzero bits
>in it. I don't think that was ever in dispute.
I'm sure it was at one point or another, because the world is full
of crackpots.
Kaz Kylheku
In article <63nb6v$l...@acf5.nyu.edu>, Mark Halvin <mh...@acf5.nyu.edu> wrote:
>Alicia Carla Longstreet <ca...@ici.net> writes:
>
>>if it were one of these). Asigning any *one* of them to a double is a
>>poor idea.
>
She probably means that assigning NULL to a double type is a poor idea
because NULL can be (void *) 0 in which case a constraint is violated.
Martin Aupperle
On Fri, 31 Oct 1997 00:02:40 -0500, Alicia Carla Longstreet
<ca...@ici.net> wrote:
>Ron Natalie wrote:
>
>> > Returning NULL can be trickey depending on what operating system you
>> > use because null is somtimes the reset vector and in the SUN I think
>> > it is a location where a program could run ( ASK OTHER PEOPLE aswell )
>> > I am not 100% sure.
>
>> Obviously. NULL is zero. Must be zero. Can't be anything else.
>> Doesn't need to be anything else.
>
>Wrong, there is no guarentee that NULL is zero. The C standard allows
>implementation to define what NULL means (usually a pointer to nowhere),
>and since C++ has no standard as of yet...
Double wrong. A pointer with value NULL is guaranteed to point to no
object. Not on the stack and not on the heap. In C++ its type cannot
be void* because otherwise you are not able to write
Foo* f = NULL;
The integer constant 0 is a special case in C++: it can be implicitely
converted to any pointer type. Therefore in C++ you *always* have
something like
#define NULL 0
and that's why NULL in fact is zero.
Please note that I did not say something about the binary
representation of 0.
------------------------------------------------
Martin Aupperle 1xx75...@compuserve.com
(replace x with 0 - fight spamming)
------------------------------------------------
Mark Halvin
Alicia Carla Longstreet <ca...@ici.net> writes:
>NULL can be defined as 0, 0L, or (void *)0 (at least it has to behave as
>if it were one of these). Asigning any *one* of them to a double is a
>poor idea.
Ok, I'll bite -- what's wrong with assigning the first two to a double?
-mark
--
---
Mark....@nyu.edu
Douglas A. Gwyn
In article <345DF8...@ici.net>,
>if it were one of these). Asigning any *one* of them to a double is a
>poor idea.
NULL can be defined as quite a few things, all of them qualifying as
null pointer constants. The above three are the most common.
There is nothing wrong with assigning 0 to a double datum; the proper
conversion is done automatically. It may be better style to write 0.0,
however, to remind the reader that the target is floating-point.
Douglas A. Gwyn
In article <63nmeh$h0e$2...@darla.visi.com>,
It's optional.
The C9x draft still contains wording to the effect that pointers
can be converted to integers and vice versa, but the conversion
doesn't have to produce usable results.
>... I'll accept this definition as improved, and in that case, yes,
>null pointers are zero.
I don't like that way of expressing things, for several reasons:
- Zero has a well-established mathematical role, and null pointers
do not fit that role (not even in the abstract).
- A so-called "null pointer" is simply a flag that the pointer does
not actually point anywhere; in some languages it would be called
"nil".
- The use of "0" to write the null pointer in C arose from a
combination of parsimony and the original muddled distinction
between B-like words and stronger data typing for pointers,
plus the fact that on the PDP-11 the representation *was* the
same as for an int 0 value. As C acquired stronger typing, the
relationship between the representation and the value-as-pointer
became looser, to the point now where pointers can have unusual
representations (e.g. on segmented architectures).
We have the same legacy for "0" meaning "false" in Boolean contexts
in C, although there the mathematical connection is more meaningful.
Alicia Carla Longstreet
You don't get the point. Since you can not be sure that any arbitrary
implementation does not choose to use the (void *)0 definition, your
assignment would be nono-portable. Maybe it works on your system, my
system, even every system that you happen to port you program to, but it
is *not* guarenteed to work on *all* systems.
double aNum = NULL;
Is non-portable, may potentially invoke undefined behavior, and is
simply bad programming in general. NULL is a pointer!
--
Actual bumper stickers found on actual cars:
****************************************************
* So many stupid people... so few comets.
* Make it idiot-proof and someone will make a better idiot.
* Ever stop to think and forget to start again?
* Keep honking...I'm reloading.
R S Haigh
> double aNum = NULL;
>
> Is non-portable, may potentially invoke undefined behavior, and is
> simply bad programming in general. NULL is a pointer!
Trouble is, it's not even that. There are pointers to this and pointers
to that, but there's no such thing as just a pointer. So in
int *p = NULL;
it's an int*, but in
double x, *p = &x;
if ( p == NULL )
it's a double*. In
(int)NULL
execl(. . ., NULL)
if ( NULL )
if ( ! NULL )
it may be any of several things, which may or may not make a difference.
And in
(char *)NULL
it's not clear what it is but it doesn't matter.
--
Kaz Kylheku
In article <34608F...@ici.net>,
Alicia Carla Longstreet <ca...@ici.net> wrote:
>Douglas A. Gwyn wrote:
>You don't get the point. Since you can not be sure that any arbitrary
He might not get the point, but it's not worth it to draw out this
insignificant thing.
>implementation does not choose to use the (void *)0 definition, your
>assignment would be nono-portable. Maybe it works on your system, my
>system, even every system that you happen to port you program to, but it
>is *not* guarenteed to work on *all* systems.
>
>double aNum = NULL;
I'm sure that Doug knows that, being involved with the C committee and
all that jazz... Let's not dwell on the obvious.
>Is non-portable, may potentially invoke undefined behavior, and is
>simply bad programming in general. NULL is a pointer!
Or rather it may potentially cause a *constraint violation* which requires
a diagnostic!
It's time to get a copy of the standard, Alicia, and learn the fine details,
such as the difference between a syntax or constraint violation and undefined
behavior!
Lawrence Kirby
In article <1997Nov5.1...@leeds.ac.uk>
ecl...@leeds.ac.uk "R S Haigh" writes:
>In article <34608F...@ici.net>, Alicia Carla Longstreet <ca...@ici.net>
> writes:
>
>> double aNum = NULL;
>>
>> Is non-portable, may potentially invoke undefined behavior, and is
>> simply bad programming in general. NULL is a pointer!
>
>Trouble is, it's not even that. There are pointers to this and pointers
>to that, but there's no such thing as just a pointer. So in
NULL is a null pointer constant. The problem is that all but one of the
types that NULL may have are integer types. :-)
> int *p = NULL;
>it's an int*, but in
NULL isn't an int * but it can be converted to one and the result is a
null pointer of type int *. Note that it is the action of the = operator
that performs the conversion from NULL to int *, it is nothing inherent to
NULL.
> double x, *p = &x;
> if ( p == NULL )
>it's a double*. In
It can be converted to a double *. Here it is the == operator that causes
that conversion.
> (int)NULL
The result of this is implementation defined. The behaviour may even be
undefined on an implementation where NULL has type void * and int isn't
"large" enough to hold a void * value.
execl(. . ., NULL)
Assuming the POSIX execl() function (which takes a variable argument list
with the last argument being a char * null pointer) this results in
undefined behaviour; NULL does not have char * type and there is no
automatic pointer conversion in a variable argument list. This should be:
execl(. . ., (char *)NULL)
> if ( NULL )
> if ( ! NULL )
Those are OK because both an integer and a pointer are valid in that context,
and in both cases it does "the right thing".
>it may be any of several things, which may or may not make a difference.
>And in
> (char *)NULL
>it's not clear what it is but it doesn't matter.
In all cases NULL is a null pointer constant which is an integral constant
with the value 0 or the same cast to void *.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
Lawrence Kirby
In article <34608F...@ici.net>
ca...@ici.net "Alicia Carla Longstreet" writes:
>Douglas A. Gwyn wrote:
>>
>> In article <345DF8...@ici.net>,
>> Alicia Carla Longstreet <ca...@ici.net> wrote:
>> >NULL can be defined as 0, 0L, or (void *)0 (at least it has to behave as
>> >if it were one of these). Asigning any *one* of them to a double is a
>> >poor idea.
>>
>> NULL can be defined as quite a few things, all of them qualifying as
>> null pointer constants. The above three are the most common.
>>
>> There is nothing wrong with assigning 0 to a double datum; the proper
>> conversion is done automatically. It may be better style to write 0.0,
>> however, to remind the reader that the target is floating-point.
>
>You don't get the point. Since you can not be sure that any arbitrary
>implementation does not choose to use the (void *)0 definition, your
>assignment would be nono-portable.
You wrote "Asigning any *one* of them to a double is a poor idea." The
clear implication is that assigning 0 or 0L to a double is a poor idea.
I suspect Douglas wondered what you meant by that.
> Maybe it works on your system, my
>system, even every system that you happen to port you program to, but it
>is *not* guarenteed to work on *all* systems.
>
>double aNum = NULL;
>
>Is non-portable, may potentially invoke undefined behavior, and is
>simply bad programming in general. NULL is a pointer!
It either works and assigns a zero value to aNum or it is a constraint
violation that requires a diagnistic. I'm sure Douglas is aware of that
however that didn't appear to be what you were implying at the top.
Jack Klein
Steve Summit <s...@eskimo.com> wrote in article
<63ihcb$1g6$1...@eskinews.eskimo.com>...
> In article <01bce682$9b14cd60$0977420c@default>, "Jack Klein"
> <jack...@worldnet.att.net> writes:
> > Stephan Wilms <Stepha...@CWA.de> wrote in article
> > <3459C2...@CWA.de>...
> >> Alicia Carla Longstreet wrote:
> >>> Ron Natalie wrote:
anything else.
> >>>
standard allows
that
> > actual representation.
>
> Ahh, the null pointer wars are back! Haven't seen these in a
> good long time.
>
> The passage in the Standard which Jack cites is, by its
inclusion
> of those two words "implementation-defined", tremendously
> misleading. The implementation gets to choose which form of
null
> pointer constant it uses in its definition of the NULL macro,
> whether 0, 0L, or some other form of 0, and whether cast to
> (void *). But the compiler is still bound by the definition
of
> null pointer constant in section 3.2.2.3/6.2.2.3:
>
> or such an expression cast to type void *, is called
> a null pointer constant.
Exactly, "a null pointer constant", not "the ONE AND ONLY" null
pointer constant.
>
> This is *the* definition of a null pointer constant; there
aren't
> any others. So while it might work, in a particular
environment,
> for a compiler's copy of <stddef.h> to contain something like
>
> #define NULL 06000
>
> , and while a conforming program might not be able to tell the
> difference, such a definition would clearly be contrary to the
> requirements of the Standard. (Furthermore, the hypothetical
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I hate to argue with the only person who's book on C I own and
have corresponded with, "implementation-defined" means exactly
that. An implementation can define ANYTHING it wants as long as
it documents it and it doesn't break conforming programs.
> non-0 definition is unnecessary and insufficient, as the
> programmer is still allowed to write his own null pointer
> constants, without using the NULL macro.)
The compiler is required to recognize a integer constant
expression which evaluates to 0 in a pointer context as a null
pointer constant. Nowhere in the standard does is say that this
is the ONLY thing which can be used to represent a null pointer
constant (such as the actual binary pattern if it is not all
bits 0), and it does not say that NULL must be defined this way.
It *might* be silly to #define NULL 0xffffffff, for example, but
it does not violate the standard.
>
> Steve Summit
> s...@eskimo.com
>
Ron Natalie
Chris Engebretson wrote:
> Just to clarify, are you really saying that the following assertation
>
> int *p = 0;
> assert ( p == 0x80000000 );
>
> might succeed, depending on the implementation? If so, I'll admit
> that it's an interesting theory, albeit one with no basis in fact.
Yes, this might exactly happen. There are no guarantees about
comparing pointers to other interger constants other than zero.
What is guaranteed not to fail is...
int *p = 0;
assert (p == 0)
and
int *p = &anything;
assert (p != 0)
And that you should be able to use the word NULL instead
of the 0 in the statements above.
I've worked on machines where exactly this sort of thing happens.
Some supercomputers encode the word size in the pointers themselves.
While C/C++ requires the compiler to fix things up so that the
assigns/comparisons against zero work (and that no object corresponds
to that address, but that's the easy case, skip over location zero
when allocating things), it's not under any other obligation to
fix up integer/pointer values.
Kaz Kylheku
In article <63vqa1$8l6$2...@darla.visi.com>,
Peter Seebach <se...@plethora.net> wrote:
>>|> It *might* be silly to #define NULL 0xffffffff, for example, but
>>|> it does not violate the standard.
>
>>It most certainly does.
>
>Indeed; the possibility of other integers converting to null pointers
>does not make them null pointer constants.
Why not? I would say that the following quote is relevant
6.4 Constant expressions
[ snip ]
An implementation may accept other forms of constant expressions.
I don't see anything wrong with an implementation that defines NULL
as 0xffffffff, as long as
(void *) 0xffffffff
and
(type *) 0xffffffff
also produce null pointers (constant or not).
This way correct uses like (void *) NULL or (char *) NULL will behave properly.
Of course, a portable program may not use these ways of writing a null pointer,
but that's a different issue from whether or not such an implementation
is conforming.
In fact, on some implementation, these may be the more ``natural'' forms for
a null pointer to have, and zeros are accepted as special cases due to
the standard's requirement. Indeed, any implementation which uses a non-zero
bit pattern for a null pointer, and which does not map the integer zero
to that bit pattern, must implement special case treatment for 0, (void *) 0
and (T *) 0, and bypass the ordinary mapping.
Alicia Carla Longstreet
Chris Engebretson wrote:
> Jack Klein writes:
> |> Steve Summit wrote:
> |> > The passage in the Standard which Jack cites is, by its inclusion
> |> > of those two words "implementation-defined", tremendously
> |> > misleading. The implementation gets to choose which form of null
> |> > pointer constant it uses in its definition of the NULL macro,
> |> > whether 0, 0L, or some other form of 0, and whether cast to
> |> > (void *). But the compiler is still bound by the definition of
> |> > null pointer constant in section 3.2.2.3/6.2.2.3:
> |> > An integral constant expression with the value 0,
> |> > or such an expression cast to type void *, is called
> |> > a null pointer constant.
> |> Exactly, "a null pointer constant", not "the ONE AND ONLY" null
> |> pointer constant.
> I'm trying very hard to see the ambiguity. I fear I can't find it.
> This is not a document known for tossing around vague terms in as
> imprecise a manner as possible. It does not say that an integral
> constant expression with the value 0, possibly cast to void *, is
> "an example of" a null pointer constant, nor does it state that it
> is "one possible definition of" a null pointer constant.
> I don't understand where the confusion is coming from.
That is because you are assuming that there is only one possible NULL
pointer constant.
By analogy, I can state that a Cadillac Seville is called an
automobile. That in no way implies that a Cadillac Seville is the
*only* thing that is called an automobile.
The wording of the standard *does* leave open the possiblilty tha there
are other things that may be called a NULL pointer constant. That may
not have been their intent.
> If an implementation is free to choose whatever arbitrary null
> pointer constant that it wishes, then what is the purpose of the
> above-quoted text? What is the purpose of the verbiage in the
> standard describing the implementation-definedness of conversion
> from an integral to pointer types (and vice versa) with a special
> exception in the case of a value of zero?
I would assume, if the intent was to leave open other possibilities,
that the Standard states that an integral constant with the value zero
is *always* a NULL pointer constant, e.g. a programmer can rely on this
in a program. It never precludes that possibility that an
implementation can not have other expressions that qualify *for that
platform* as a NULL pointer constant. Again, I have no idea what their
intent was other than an examination of hte standard.
Peter Seebach
In article <01bceb2f$b4369ec0$0376420c@default>,
Jack Klein <jack...@worldnet.att.net> wrote:
>I hate to argue with the only person who's book on C I own and
>have corresponded with, "implementation-defined" means exactly
>that. An implementation can define ANYTHING it wants as long as
>it documents it and it doesn't break conforming programs.
And, and this is very important, as long as it does not violate any
other statement made in the standard! The standard says that NULL
is 'an implementation defined null pointer constant'. What is a
'null pointer constant'?
An integral constant expression with the value 0, or such an
expression cast to type void *, is called a null pointer
constant.
Thus, any "null pointer constant" must match that definition.
>The compiler is required to recognize a integer constant
>expression which evaluates to 0 in a pointer context as a null
>pointer constant. Nowhere in the standard does is say that this
>is the ONLY thing which can be used to represent a null pointer
>constant (such as the actual binary pattern if it is not all
>bits 0), and it does not say that NULL must be defined this way.
>It *might* be silly to #define NULL 0xffffffff, for example, but
>it does not violate the standard.
It certainly does! When the standard gives a list, that list is
exhaustive unless otherwise specified. This is why we had a long
debate about allowing implementations to provide additional
integer types.
The standard gives two classes of things which are null pointer constants;
'0xffffffff' does not match either, thus, it is not a null pointer
constant.
When we say that '__FILE__' is "a character string literal", this does
not mean that an implementation is allowed to define file names such
that '__FILE__' is no longer a valid string literal.
Chris Engebretson
In article <01bceb2f$b4369ec0$0376420c@default>, "Jack Klein" <jack...@worldnet.att.net> writes:
|> Steve Summit <s...@eskimo.com> wrote in article
|> <63ihcb$1g6$1...@eskinews.eskimo.com>...
|>
|> > The passage in the Standard which Jack cites is, by its inclusion
|> > of those two words "implementation-defined", tremendously
|> > misleading. The implementation gets to choose which form of null
|> > pointer constant it uses in its definition of the NULL macro,
|> > whether 0, 0L, or some other form of 0, and whether cast to
|> > (void *). But the compiler is still bound by the definition of
|> > null pointer constant in section 3.2.2.3/6.2.2.3:
|> >
|> > An integral constant expression with the value 0,
|> > or such an expression cast to type void *, is called
|> > a null pointer constant.
|>
|> Exactly, "a null pointer constant", not "the ONE AND ONLY" null
|> pointer constant.
I'm trying very hard to see the ambiguity. I fear I can't find it.
This is not a document known for tossing around vague terms in as
imprecise a manner as possible. It does not say that an integral
constant expression with the value 0, possibly cast to void *, is
"an example of" a null pointer constant, nor does it state that it
is "one possible definition of" a null pointer constant.
I don't understand where the confusion is coming from.
If an implementation is free to choose whatever arbitrary null
pointer constant that it wishes, then what is the purpose of the
above-quoted text? What is the purpose of the verbiage in the
standard describing the implementation-definedness of conversion
from an integral to pointer types (and vice versa) with a special
exception in the case of a value of zero?
|> > This is *the* definition of a null pointer constant; there aren't
|> > any others. So while it might work, in a particular environment,
|> > for a compiler's copy of <stddef.h> to contain something like
|> >
|> > #define NULL 06000
|> >
|> > , and while a conforming program might not be able to tell the
|> > difference, such a definition would clearly be contrary to the
|> > requirements of the Standard. (Furthermore, the hypothetical
|> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|>
|> I hate to argue with the only person who's book on C I own and
|> have corresponded with, "implementation-defined" means exactly
|> that. An implementation can define ANYTHING it wants as long as
|> it documents it and it doesn't break conforming programs.
I thought Steve did a more than adequate job explaining this, so
I'm not going to try to do it again. The phrase "implementation
defined" in this context is closely related to the definition of
a null pointer constant. I'd agree that the phrase's presence
might be misleading if you weren't aware of what a null pointer
constant actually is, but inasmuch as that definition has been
posted at least a half dozen times, we're past all that.
When the standard leaves behavior as implementation defined, it
is, essentially, asking the vendor to make a choice between a
relatively narrow set of possibilities. An example is the three
different character types; given signed char and unsigned char,
"plain" char is required to have the same range and representation
of one of the first two types. *Which* of the two types is
implementation defined. Another example along the same lines is
the result of right-shifting a negative integral value.
With respect to the definition of NULL, the standard leaves it to
the implementation to define *how* it wishes to express an integral
constant of zero, possibly cast to void. It does *not* give it
license to break the requirements of 6.2.2.3. It might choose
((void *) 0). It might choose (9 / 10). It *cannot* choose 1.
Okay, so maybe I did try to explain it again. :-)
|> > non-0 definition is unnecessary and insufficient, as the
|> > programmer is still allowed to write his own null pointer
|> > constants, without using the NULL macro.)
|>
|> The compiler is required to recognize a integer constant
|> expression which evaluates to 0 in a pointer context as a null
|> pointer constant. Nowhere in the standard does is say that this
|> is the ONLY thing which can be used to represent a null pointer
|> constant (such as the actual binary pattern if it is not all
|> bits 0), and it does not say that NULL must be defined this way.
Nobody has ever stated in this thread that a machine-level null
pointer constant must consist of all-bits-zero. That's not the
point, and it's not what's in contention here. What's being
discussed here is the language level itself, where null pointer
constants are zero. Game, set and match.
Just to clarify, are you really saying that the following assertation
int *p = 0;
assert ( p == 0x80000000 );
might succeed, depending on the implementation? If so, I'll admit
that it's an interesting theory, albeit one with no basis in fact.
|> It *might* be silly to #define NULL 0xffffffff, for example, but
|> it does not violate the standard.
It most certainly does.
Regards,
--
Chris Engebretson --- Hughes STX Corporation | Ph#: (605)594-6829
USGS EROS Data Center, Sioux Falls, SD 57198 | Fax: (605)594-6940
Peter Seebach
In article <EJAH...@igsrsparc2.er.usgs.gov>,
Chris Engebretson <enge...@sg1.cr.usgs.gov> wrote:
>Just to clarify, are you really saying that the following assertation
> int *p = 0;
> assert ( p == 0x80000000 );
>might succeed, depending on the implementation? If so, I'll admit
>that it's an interesting theory, albeit one with no basis in fact.
As is, it's a constraint violation. However,
assert ( p == (int *) 0x80000000 );
may, indeed, succeed - no one said that *ONLY* null pointer constants
could convert to null pointers.
>|> It *might* be silly to #define NULL 0xffffffff, for example, but
>|> it does not violate the standard.
>It most certainly does.
Indeed; the possibility of other integers converting to null pointers
does not make them null pointer constants.
-s
Chris Engebretson
|> In article <EJAH...@igsrsparc2.er.usgs.gov>,
|> Chris Engebretson <enge...@sg1.cr.usgs.gov> wrote:
|>
|> >Just to clarify, are you really saying that the following assertation
|>
|> > int *p = 0;
|> > assert ( p == 0x80000000 );
|>
|> >might succeed, depending on the implementation? If so, I'll admit
|> >that it's an interesting theory, albeit one with no basis in fact.
|>
|> As is, it's a constraint violation.
That's the whole point;
#include <stdlib.h>
int *p = 0;
assert ( p == NULL );
must certainly work given a legal definition of NULL, but nothing can
be said about an illegal definition (i.e., 0x80000000 as given above.)
With such a definition, the above trivially-well-defined example will
likely not even compile. This is what shoots holes in arguments that
NULL can be #defined to expand to whatever the implementor chooses.
|> However,
|>
|> assert ( p == (int *) 0x80000000 );
|>
|> may, indeed, succeed - no one said that *ONLY* null pointer constants
|> could convert to null pointers.
This is true.
Mark Halvin
Alicia Carla Longstreet <ca...@ici.net> writes:
>> |> Steve Summit wrote:
>> |> > But the compiler is still bound by the definition of
>> |> > null pointer constant in section 3.2.2.3/6.2.2.3:
>> |> > An integral constant expression with the value 0,
>> |> > or such an expression cast to type void *, is called
>> |> > a null pointer constant.
>> |> Exactly, "a null pointer constant", not "the ONE AND ONLY" null
>> |> pointer constant.
>
>> I'm trying very hard to see the ambiguity. I fear I can't find it.
>
>> This is not a document known for tossing around vague terms in as
>> imprecise a manner as possible. It does not say that an integral
>> constant expression with the value 0, possibly cast to void *, is
>> "an example of" a null pointer constant, nor does it state that it
>> is "one possible definition of" a null pointer constant.
>
>> I don't understand where the confusion is coming from.
>That is because you are assuming that there is only one possible NULL
>pointer constant.
Okay, back that statement up -- don't just leave it sitting out there.
>By analogy, I can state that a Cadillac Seville is called an
>automobile. That in no way implies that a Cadillac Seville is the
>*only* thing that is called an automobile.
I'm sorry, but your analogies suck. They don't clarify anything.
~~~~
>The wording of the standard *does* leave open the possiblilty tha there
>are other things that may be called a NULL pointer constant. That may
>not have been their intent.
Do you have a copy of the standard? Are you making this judgement after
having read other passages in the same document, or are you just utilizing
your famous Command of the English Language?
>> If an implementation is free to choose whatever arbitrary null
>> pointer constant that it wishes, then what is the purpose of the
>> above-quoted text? What is the purpose of the verbiage in the
>> standard describing the implementation-definedness of conversion
>> from an integral to pointer types (and vice versa) with a special
>> exception in the case of a value of zero?
>I would assume, if the intent was to leave open other possibilities,
>that the Standard states that an integral constant with the value zero
>is *always* a NULL pointer constant, e.g. a programmer can rely on this
>in a program. It never precludes that possibility that an
>implementation can not have other expressions that qualify *for that
>platform* as a NULL pointer constant.
And you could conceivably be correct. OTOH, you obviously don't know what
you're talking about. You've gone from proclaiming yourself the Final
Authority on the "real meaning" of the statements other participants in
this^H^H^H^Hthese newsgroups write to proclaiming yourself capable of
interpreting the intent of the ANSI C Committee. And I still don't think
you've even seen a copy of the standard yourself. Do correct me if I'm
wrong on that point, because if you HAVE read the standard -- and are
still as willfully ignorant as you've been demonstrating -- you need to
write a book annotating it; it could make a silk purse out of Herbert
Schildt's ear.
> Again, I have no idea what their
>intent was other than an examination of hte standard.
Exactly. You seem to "have no idea" -- please educate yourself and quit
babbling. Aren't you embarassed YET?
--
---
Mark....@nyu.edu
Douglas A. Gwyn
In article <34608F...@ici.net>,
Alicia Carla Longstreet <ca...@ici.net> wrote:
>Douglas A. Gwyn wrote:
>> In article <345DF8...@ici.net>, Alicia Carla Longstreet <ca...@ici.net> wrote:
>> >NULL can be defined as 0, 0L, or (void *)0 (at least it has to behave as
>> >if it were one of these). Asigning any *one* of them to a double is a
>> >poor idea.
>> conversion is done automatically. It may be better style to write 0.0,
>> however, to remind the reader that the target is floating-point.
>You don't get the point. Since you can not be sure that any arbitrary
>implementation does not choose to use the (void *)0 definition, your
>system, even every system that you happen to port you program to, but it
>is *not* guarenteed to work on *all* systems.
>double aNum = NULL;
You're lecturing the wrong person on C portability...
I totally agree that assigning NULL to a double datum is wrong.
I was merely responding to what you *said*,
not necessarily what you *meant to say*.
It is NOT TRUE that assigning any one of: 0, 0L, or (void*)0
to a double is a poor idea;
double a = 0; /* is fine */
it is, however, true that assigning an UNKNOWN one of them
to a double is a bad idea,
precisely because then you might be trying to assign (void*)0
to a double.
I think we're in agreement on the actual issue here.
double a = NULL; /* is stupid */
Douglas A. Gwyn
In article <3463D9...@ici.net>,
>that the Standard states that an integral constant with the value zero
>is *always* a NULL pointer constant, e.g. a programmer can rely on this
>in a program.
The C standard doesn't use terms like "always"; it describes things
in terms of requirements upon strictly conforming programs and upon
conforming implementations, and in those requirements key terms are
"undefined behavior", "implementation-defined", etc., which in turn
have their own technical definitions.
When the standard says that a null pointer constant is an integral
constant expression with the value 0, or such a type cast to type
void *, it means that it is "always" that, *in a conforming
implementation*. Nothing can be said about implementations that do
not conform to all the requirements of the standard, other that
they do not conform to all the requirements of the standard.
Michael Rubenstein
>Chris Engebretson wrote:
>
>> Jack Klein writes:
>
>> |> Steve Summit wrote:
>
>> |> > The passage in the Standard which Jack cites is, by its inclusion
>> |> > of those two words "implementation-defined", tremendously
>> |> > misleading. The implementation gets to choose which form of null
>> |> > pointer constant it uses in its definition of the NULL macro,
>> |> > whether 0, 0L, or some other form of 0, and whether cast to
>> |> > (void *). But the compiler is still bound by the definition of
>> |> > null pointer constant in section 3.2.2.3/6.2.2.3:
>
>> |> > An integral constant expression with the value 0,
>> |> > or such an expression cast to type void *, is called
>> |> > a null pointer constant.
>
>> |> Exactly, "a null pointer constant", not "the ONE AND ONLY" null
>> |> pointer constant.
>
>> I'm trying very hard to see the ambiguity. I fear I can't find it.
>
>> This is not a document known for tossing around vague terms in as
>> imprecise a manner as possible. It does not say that an integral
>> constant expression with the value 0, possibly cast to void *, is
>> "an example of" a null pointer constant, nor does it state that it
>> is "one possible definition of" a null pointer constant.
>
>> I don't understand where the confusion is coming from.
>
>That is because you are assuming that there is only one possible NULL
>pointer constant.
>By analogy, I can state that a Cadillac Seville is called an
>automobile. That in no way implies that a Cadillac Seville is the
>*only* thing that is called an automobile.
>
>The wording of the standard *does* leave open the possiblilty tha there
>are other things that may be called a NULL pointer constant. That may
>not have been their intent.
6.2.2.3 isn't just saying that these are examples of null pointer
constants. The term "null pointer constant" is italicized, meaning
that this is the definition of a null pointer constant.
If we define an rational number as one which may be expressed as the
ratio of two integers, are you going to claim that sqrt(2) may be
irrational since we haven't said that only numbers which can be
expressed as the ratio of two integers are rational?
>
>> If an implementation is free to choose whatever arbitrary null
>> pointer constant that it wishes, then what is the purpose of the
>> above-quoted text? What is the purpose of the verbiage in the
>> standard describing the implementation-definedness of conversion
>> from an integral to pointer types (and vice versa) with a special
>> exception in the case of a value of zero?
>
>I would assume, if the intent was to leave open other possibilities,
>that the Standard states that an integral constant with the value zero
>is *always* a NULL pointer constant, e.g. a programmer can rely on this
>in a program. It never precludes that possibility that an
>implementation can not have other expressions that qualify *for that
>platform* as a NULL pointer constant. Again, I have no idea what their
>intent was other than an examination of hte standard.
Let me get this straight. The standard DEFINES a null pointer
constant as "an integral constant expression with the value 0, or such
an expression cast to type void *" and you don't think that indicates
that its intent is that the term "null pointer constant" means an an
integral constant expression or an such an expression cast to type
void*?
Fascinating.
Michael M Rubenstein
Alicia Carla Longstreet
Douglas A. Gwyn wrote:
>
> In article <3463D9...@ici.net>,
> Alicia Carla Longstreet <ca...@ici.net> wrote:
> >I would assume, if the intent was to leave open other possibilities,
> >that the Standard states that an integral constant with the value zero
> >is *always* a NULL pointer constant, e.g. a programmer can rely on this
> >in a program.
>
> in terms of requirements upon strictly conforming programs and upon
> conforming implementations, and in those requirements key terms are
> "undefined behavior", "implementation-defined", etc., which in turn
> have their own technical definitions.
>
> When the standard says that a null pointer constant is an integral
> constant expression with the value 0, or such a type cast to type
> void *, it means that it is "always" that, *in a conforming
> implementation*. Nothing can be said about implementations that do
> not conform to all the requirements of the standard, other that
> they do not conform to all the requirements of the standard.
Now you are twisting the words around. The passage *didn't* state that
a NULL pointer constant is an integral expression with a zero value. It
said an integral constant expression with the value 0, ... is called a
null pointer constant.
Those two statments have *very* different meanings. The first, yours,
would in fact be intrpreted to mean that a NULL pointer constant is
*always* and intregral expression with a value of 0, the second (and the
quote from the Standard) merely specifies that an intregral expression
with a value of 0 is, and possibly one of exveral expressions, called a
NULL pointer constant.
If the standard had worded it as you did then I would agree that the
standard did not intend to leave room for anything else to be called a
null pointer constant. Based on the passage cited by Jack Klien one
would have to conclude that the standard left room for other constructs
that can be called null pointer constants. Now if you can find another
passage in the standard to support you position.
Alicia Carla Longstreet
> >> |> > null pointer constant in section 3.2.2.3/6.2.2.3:
> >> |> > An integral constant expression with the value 0,
> >> |> > or such an expression cast to type void *, is called
> >> |> > a null pointer constant.
> >> |> Exactly, "a null pointer constant", not "the ONE AND ONLY" null
> >> |> pointer constant.
> >> I'm trying very hard to see the ambiguity. I fear I can't find it.
> >> I don't understand where the confusion is coming from.
> >That is because you are assuming that there is only one possible NULL
> >pointer constant.
> Okay, back that statement up -- don't just leave it sitting out there.
Reread his post, it is clear that it is his belief that there exists, in
terms of the standard, one, and only one, null pointer constant.
> >By analogy, I can state that a Cadillac Seville is called an
> >automobile. That in no way implies that a Cadillac Seville is the
> >*only* thing that is called an automobile.
> I'm sorry, but your analogies suck. They don't clarify anything.
I am sorry that you do not understand a simple analogy.
> >The wording of the standard *does* leave open the possiblilty tha there
> >are other things that may be called a NULL pointer constant. That may
> >not have been their intent.
> Do you have a copy of the standard? Are you making this judgement after
> having read other passages in the same document, or are you just utilizing
> your famous Command of the English Language?
You can see the cited passage as well as I. Why don't you read it. I
will grant you that I am assuming that My Klein cited all relevant
passages, and that my analysis is based on what was presented. The
implications of the cited passage are quite clear. If you have another
passage from the standard that provides more enlightenment on the
subject, please post it.
> >> If an implementation is free to choose whatever arbitrary null
> >> pointer constant that it wishes, then what is the purpose of the
> >> above-quoted text? What is the purpose of the verbiage in the
> >> standard describing the implementation-definedness of conversion
> >> from an integral to pointer types (and vice versa) with a special
> >> exception in the case of a value of zero?
> > I would assume, if the intent was to leave open other possibilities,
> > that the Standard states that an integral constant with the value zero
> > is *always* a NULL pointer constant, e.g. a programmer can rely on this
> > in a program. It never precludes that possibility that an
> > implementation can not have other expressions that qualify *for that
> > platform* as a NULL pointer constant.
> And you could conceivably be correct. OTOH, you obviously don't know what
> you're talking about.
Really, did you even read the passage cited:
An integral constant expression with the value 0,
or such an expression cast to type void *, is called
a null pointer constant.
It seems clear enough, it states that an integral constant expression
with the value 0 is call a null pointer constant. It makes no
representation one way or another as t o whether or not this is the only
null pointer constant or wheterh anything else is or can be called a
null pointer constant. Don't read more into words than are there, for
the same reason that you should not read less into words than are there.
> ...to proclaiming yourself capable of interpreting the intent of the ANSI
> C Committee.
Of course I am capable of interpreting the intent of the ANSI C
committee, as are you, and anybody else who is capable of reading the
standard. Every day men and women in this country proclaim themselves
capable of interpreting the intent of the founding fathers. It comes
from reading their works and knowing that their intent is embodied in
their work. Unless you assume that they did not outline their intent in
the words of the standard but just threw out any old thing.
> And I still don't think you've even seen a copy of the standard
> yourself. Do correct me if I'm wrong on that point, because if you
> HAVE read the standard -- and are still as willfully ignorant as you've
> been demonstrating -- you need to write a book annotating it; it could make
> a silk purse out of Herbert Schildt's ear.
Maybe you should read the standard, or take a course in English and
reread the standard. You have shown a great tendency to read you own
private meaning into everything you read or say. You ignore semantics,
you ignore emotional content, you simply assume that everybody will
understand *exactly* what you mean. Then you deride me for actually
posting what I believe or want a term to mean, in order to facilitate
communication.
You have no actually understood anything I have said.
> > Again, I have no idea what their intent was other than an examination of hte standard.
> Exactly. You seem to "have no idea" -- please educate yourself and quit
> babbling. Aren't you embarassed YET?
Babbling? Methinks thou shouldst peer directly into a mirror and mouth
that statemnt.
Horst Kraemer
>Now you are twisting the words around. The passage *didn't* state that
>a NULL pointer constant is an integral expression with a zero value. It
>said an integral constant expression with the value 0, ... is called a
>null pointer constant.
And this has doubtlessly the same meaning. In mathematics and in every
scientific context
"... is _called_ foo"
means
"... is the definition of foo, nothing else is a foo"
and not
... is a foo
The sentence
"An integer which leaves a remainder of 1 when divided by two
is called "odd integer"
excludes that 2 may be an odd integer.
Regards
Horst
Alicia Carla Longstreet
Michael Rubenstein wrote:
>
> On Fri, 07 Nov 1997 22:16:45 -0500, Alicia Carla Longstreet
> <ca...@ici.net> wrote:
>
> >Chris Engebretson wrote:
> >
> >> Jack Klein writes:
> >
> >> |> Steve Summit wrote:
> >> |> > null pointer constant in section 3.2.2.3/6.2.2.3:
> >
> >> |> > An integral constant expression with the value 0,
> >> |> > or such an expression cast to type void *, is called
> >> |> > a null pointer constant.
> constants. The term "null pointer constant" is italicized, meaning
If that is true then they picked an incredibly poor way to state that.
If that was there intent they could have said:
A null pointer constant is an integral constant expression
with the value 0, or such and expression cast to type void *.
That would have clearly left no room for anything else to be called a
null pointer constant. The way they *actually* worded it, regardless of
any part being in italics, *does* appear to leave room for additional
constructs to ba called null pointer constants.
> If we define an rational number as one which may be expressed as the
> ratio of two integers, are you going to claim that sqrt(2) may be
> irrational since we haven't said that only numbers which can be
> expressed as the ratio of two integers are rational?
Certainly sgrt(2) is not a rational number! This is exactly the tack
you seem to be taking with respect to the standard. Logically, if you
define a rational number as above, then you are precluding all numbers
that cannot be expressed as a ration of two integers as rational, Pi,
the square root of two are both examples of numbers that cannot be
expressed as a ratio of two integers. The standard did not define a
null pointer constant as an integral constant expression having a value
of zero, it simply stated (or at least the cited passage) that this
integer 0 is *called* a null pointer constant. That certainly does not
exclude anything else from being *called* a null pointer constant.
> >> If an implementation is free to choose whatever arbitrary null
> >> pointer constant that it wishes, then what is the purpose of the
> >> above-quoted text? What is the purpose of the verbiage in the
> >> standard describing the implementation-definedness of conversion
> >> from an integral to pointer types (and vice versa) with a special
> >> exception in the case of a value of zero?
> >I would assume, if the intent was to leave open other possibilities,
> >that the Standard states that an integral constant with the value zero
> >is *always* a NULL pointer constant, e.g. a programmer can rely on this
> >in a program. It never precludes the possibility that an
> >implementation can not have other expressions that qualify *for that
> >platform* as a NULL pointer constant. Again, I have no idea what their
> >intent was other than an examination of the standard.
> Let me get this straight. The standard DEFINES a null pointer
> constant as "an integral constant expression with the value 0, or such
> an expression cast to type void *" and you don't think that indicates
> that its intent is that the term "null pointer constant" means an an
> integral constant expression or an such an expression cast to type
> void*?
Assuming that the cited passage is the primary reference to null pointer
constants, there is no *definition*. The cited passage does *not*
define a null pointer constant, it only provides an example of a null
pointer constant. Is there another passage in the standard that *does*
define a null pointer constant? If so, please cite that passage.
> Fascinating.
Yes absolutely.
Michael Rubenstein
On Sat, 08 Nov 1997 09:46:06 -0500, Alicia Carla Longstreet
<ca...@ici.net> wrote:
>Michael Rubenstein wrote:
>>
>> On Fri, 07 Nov 1997 22:16:45 -0500, Alicia Carla Longstreet
>> <ca...@ici.net> wrote:
>>
>> >Chris Engebretson wrote:
>> >
>> >> Jack Klein writes:
>> >
>> >> |> Steve Summit wrote:
>> >> |> > But the compiler is still bound by the definition of
>> >> |> > null pointer constant in section 3.2.2.3/6.2.2.3:
>> >
>> >> |> > An integral constant expression with the value 0,
>> >> |> > or such an expression cast to type void *, is called
>> >> |> > a null pointer constant.
>
>> >> If an implementation is free to choose whatever arbitrary null
>> >> pointer constant that it wishes, then what is the purpose of the
>> >> above-quoted text? What is the purpose of the verbiage in the
>> >> standard describing the implementation-definedness of conversion
>> >> from an integral to pointer types (and vice versa) with a special
>> >> exception in the case of a value of zero?
>
>> >I would assume, if the intent was to leave open other possibilities,
>> >that the Standard states that an integral constant with the value zero
>> >is *always* a NULL pointer constant, e.g. a programmer can rely on this
>> >in a program. It never precludes the possibility that an
>> >implementation can not have other expressions that qualify *for that
>> >platform* as a NULL pointer constant. Again, I have no idea what their
>> >intent was other than an examination of the standard.
>
>> Let me get this straight. The standard DEFINES a null pointer
>> constant as "an integral constant expression with the value 0, or such
>> an expression cast to type void *" and you don't think that indicates
>> that its intent is that the term "null pointer constant" means an an
>> integral constant expression or an such an expression cast to type
>> void*?
>
>Assuming that the cited passage is the primary reference to null pointer
>constants, there is no *definition*. The cited passage does *not*
>define a null pointer constant, it only provides an example of a null
>pointer constant. Is there another passage in the standard that *does*
>define a null pointer constant? If so, please cite that passage.
That is the definition of a null pointer constant. The term "null
pointer constant" is in italics. That means it is the definition of
the term. In the standard, putting a term in italics means that the
term is being defined. In most places (subclause 3 being the only
exception I know off hand) the standard indicates a definition only by
putting the term in italics.
Michael M Rubenstein
Lawrence Kirby
In article <346479...@ici.net>
ca...@ici.net "Alicia Carla Longstreet" writes:
>Michael Rubenstein wrote:
>>
>> On Fri, 07 Nov 1997 22:16:45 -0500, Alicia Carla Longstreet
>> <ca...@ici.net> wrote:
>>
>> >Chris Engebretson wrote:
>> >
>> >> Jack Klein writes:
>> >
>> >> |> Steve Summit wrote:
>> >> |> > But the compiler is still bound by the definition of
>> >> |> > null pointer constant in section 3.2.2.3/6.2.2.3:
>> >
>> >> |> > An integral constant expression with the value 0,
>> >> |> > or such an expression cast to type void *, is called
>> >> |> > a null pointer constant.
>
>> 6.2.2.3 isn't just saying that these are examples of null pointer
>> constants. The term "null pointer constant" is italicized, meaning
>> that this is the definition of a null pointer constant.
>
>If that is true then they picked an incredibly poor way to state that.
I've always considered it clear enough. The standard specifies a construct
and defines a label for it. Nowhere does it permit that label to refer
to anything else. We aren't talking about free prose here, we are talking
about a standards document.
>If that was there intent they could have said:
>
> A null pointer constant is an integral constant expression
> with the value 0, or such and expression cast to type void *.
That is another way of saying the same thing.
>That would have clearly left no room for anything else to be called a
>null pointer constant. The way they *actually* worded it, regardless of
>any part being in italics, *does* appear to leave room for additional
>constructs to ba called null pointer constants.
There is no room for anything else as things stand. The only difference
is in approach. The standard defines a construct and then gives it a label.
You want to define the label and then specify what it means. The overall
effect is the same.
>> If we define an rational number as one which may be expressed as the
>> ratio of two integers, are you going to claim that sqrt(2) may be
>> irrational since we haven't said that only numbers which can be
>> expressed as the ratio of two integers are rational?
>
>Certainly sgrt(2) is not a rational number! This is exactly the tack
>you seem to be taking with respect to the standard. Logically, if you
>define a rational number as above, then you are precluding all numbers
>that cannot be expressed as a ration of two integers as rational, Pi,
>the square root of two are both examples of numbers that cannot be
>expressed as a ratio of two integers. The standard did not define a
>null pointer constant as an integral constant expression having a value
>of zero, it simply stated (or at least the cited passage) that this
>integer 0 is *called* a null pointer constant. That certainly does not
>exclude anything else from being *called* a null pointer constant.
"A number that can be expressed as the ratio of 2 integers is called a
rational number".
Are you suggesting that this permits sqrt(2) to be called a rational number?
>Assuming that the cited passage is the primary reference to null pointer
>constants, there is no *definition*. The cited passage does *not*
>define a null pointer constant, it only provides an example of a null
>pointer constant. Is there another passage in the standard that *does*
>define a null pointer constant? If so, please cite that passage.
The passage most certainly does define a null pointer constant, which is
emphasised by the fact that the term is italicised.
Mark Halvin
Alicia Carla Longstreet <ca...@ici.net> writes:
>Mark Halvin wrote:
>
>> Alicia Carla Longstreet <ca...@ici.net> writes:
>
>> >> |> Steve Summit wrote:
>
>> >> |> > But the compiler is still bound by the definition of
>> >> |> > null pointer constant in section 3.2.2.3/6.2.2.3:
>
>> >> |> > An integral constant expression with the value 0,
>> >> |> > or such an expression cast to type void *, is called
>> >> |> > a null pointer constant.
>
>> >> |> Exactly, "a null pointer constant", not "the ONE AND ONLY" null
>> >> |> pointer constant.
>> >> I'm trying very hard to see the ambiguity. I fear I can't find it.
>> >> I don't understand where the confusion is coming from.
>
>> >That is because you are assuming that there is only one possible NULL
>> >pointer constant.
>
>> Okay, back that statement up -- don't just leave it sitting out there.
>Reread his post, it is clear that it is his belief that there exists, in
>terms of the standard, one, and only one, null pointer constant.
Because that is the style in which the standard is written. It is not a
document that tends to leave things unstated. If they had intended to
allow an implementation to define other null pointer constant forms, they
surely could have and (in the opinion of many) would have.
>> >By analogy, I can state that a Cadillac Seville is called an
>> >automobile. That in no way implies that a Cadillac Seville is the
>> >*only* thing that is called an automobile.
>
>> I'm sorry, but your analogies suck. They don't clarify anything.
>I am sorry that you do not understand a simple analogy.
But that's the point, isn't it? I understand analogies quite well, thank
you. But they're usually trotted out by people who have run out of
supportive data for their position -- and are inherently self-serving.
Don't you agree?
>> >The wording of the standard *does* leave open the possiblilty tha there
>> >are other things that may be called a NULL pointer constant. That may
>> >not have been their intent.
>
>> Do you have a copy of the standard? Are you making this judgement after
>> having read other passages in the same document, or are you just utilizing
>> your famous Command of the English Language?
>You can see the cited passage as well as I. Why don't you read it. I
>will grant you that I am assuming that My Klein cited all relevant
>passages, and that my analysis is based on what was presented. The
>implications of the cited passage are quite clear. If you have another
>passage from the standard that provides more enlightenment on the
>subject, please post it.
Read the standard yourself. If you'd read my message, you'd see that I was
asking you to support your contention, that's all. And I thought it was
Mr. Summit who presented the passage from the standard.
>> >> If an implementation is free to choose whatever arbitrary null
>> >> pointer constant that it wishes, then what is the purpose of the
>> >> above-quoted text? What is the purpose of the verbiage in the
>> >> standard describing the implementation-definedness of conversion
>> >> from an integral to pointer types (and vice versa) with a special
>> >> exception in the case of a value of zero?
>
>> > I would assume, if the intent was to leave open other possibilities,
>> > that the Standard states that an integral constant with the value zero
>> > is *always* a NULL pointer constant, e.g. a programmer can rely on this
>> > in a program. It never precludes that possibility that an
>> > implementation can not have other expressions that qualify *for that
>> > platform* as a NULL pointer constant.
>
>> And you could conceivably be correct. OTOH, you obviously don't know what
>> you're talking about.
>Really, did you even read the passage cited:
> An integral constant expression with the value 0,
> or such an expression cast to type void *, is called
> a null pointer constant.
Of course I did. And I interpreted it in the context of the other passages
in the document.
>It seems clear enough, it states that an integral constant expression
>with the value 0 is call a null pointer constant. It makes no
>representation one way or another as t o whether or not this is the only
>null pointer constant or wheterh anything else is or can be called a
>null pointer constant. Don't read more into words than are there, for
>the same reason that you should not read less into words than are there.
This is a LANGUAGE DESCRIPTION! It is intended to be a precise
specification for the behavior and syntax of C. Are you telling me that
the committee decided to just leave this up to interpretation? As I said
before, you may be correct, but I'd feel much more confident if I were you
if I could supply another example where the standard's language was
similarly vague.
Remember, this is not literature -- it's a standards document.
>> ...to proclaiming yourself capable of interpreting the intent of the ANSI
>> C Committee.
>Of course I am capable of interpreting the intent of the ANSI C
>committee, as are you, and anybody else who is capable of reading the
>standard.
So you have read the standard? Great, where else do they leave something
so fundamental open to such interpretation?
> Unless you assume that they did not outline their intent in
>the words of the standard but just threw out any old thing.
No, that's what *you* seem to think. You seem to be saying that they
*could* have said, "An implementation may also define other null pointer
constants.", but just decided not to. Fine, but why do you think that?
>> And I still don't think you've even seen a copy of the standard
>> yourself. Do correct me if I'm wrong on that point, because if you
>> HAVE read the standard -- and are still as willfully ignorant as you've
>> been demonstrating -- you need to write a book annotating it; it could make
>> a silk purse out of Herbert Schildt's ear.
>Maybe you should read the standard, or take a course in English and
>reread the standard. You have shown a great tendency to read you own
>private meaning into everything you read or say. You ignore semantics,
>you ignore emotional content, you simply assume that everybody will
>understand *exactly* what you mean. Then you deride me for actually
>posting what I believe or want a term to mean, in order to facilitate
>communication.
I should be writing that to you. Who is famous for reinventing meanings
for words?
And what "emotional content"? It's a LANGUAGE SPECIFICATION, remember.
>You have no actually understood anything I have said.
>
>> > Again, I have no idea what their intent was other than an examination of hte standard.
>
>> Exactly. You seem to "have no idea" -- please educate yourself and quit
>> babbling. Aren't you embarassed YET?
>Babbling? Methinks thou shouldst peer directly into a mirror and mouth
>that statemnt.
--
Alicia Carla Longstreet
Horst Kraemer wrote:
> Alicia Carla Longstreet wrote:
> > Now you are twisting the words around. The passage *didn't* state that
> > a NULL pointer constant is an integral expression with a zero value. It
> > null pointer constant.
> And this has doubtlessly the same meaning. In mathematics and in every
> scientific context
> "... is _called_ foo"
> means
> "... is the definition of foo, nothing else is a foo"
Not if they are writing in English. In English the two statements have
too very different meanings. It may well be the authors intent, but if
so the author has made an extremely bad choice of langauge.
> and not
> ... is a foo
> The sentence
> "An integer which leaves a remainder of 1 when divided by two
> is called "odd integer"
> excludes that 2 may be an odd integer.
Unfortunatly it does not, at least with that definition. Anything that
billed itself as a scientific document and containted that definition
would be suspect. I probably wouldn't even bother with such a
document. Either the authors don't fully understand English or they
don't fully understand.
I do not ever recall a defintion of odd that did not start with "An odd
integer is..."
Your defintion is not correct by any standards.
--
By speaking, by thinking, we undertake to clarify things,
and that forces us to exacerbate them, dislocate them,
schematize them. Every concept is in itself an exaggeration.
José Ortega y Gasset
Alicia Carla Longstreet
Michael Rubenstein wrote:
> That is the definition of a null pointer constant. The term "null
> pointer constant" is in italics. That means it is the definition of
> the term. In the standard, putting a term in italics means that the
> term is being defined. In most places (subclause 3 being the only
> exception I know off hand) the standard indicates a definition only by
> putting the term in italics.
Okay, so they made a very poor choice of phraseology, rather silly of
them wasn't it. I might suggest that the C9X committee correct this poor
phraseology and eliminate the ambiguity, especially since there are
mediums where the italics may be lost.
BTW, what do you do on an architecture where there is an actual memory
address location 0? How would the implementation address it?
Alicia Carla Longstreet
Lawrence Kirby wrote:
> Alicia Carla Longstreet writes:
> >Michael Rubenstein wrote:
> >> Alicia Carla Longstreet wrote:
> >> >Chris Engebretson wrote:
> >> >> |> > An integral constant expression with the value 0,
> >> >> |> > or such an expression cast to type void *, is called
> >> >> |> > a null pointer constant.
> >> 6.2.2.3 isn't just saying that these are examples of null pointer
> >> constants. The term "null pointer constant" is italicized, meaning
> >> that this is the definition of a null pointer constant.
> >If that is true then they picked an incredibly poor way to state that.
> I've always considered it clear enough. The standard specifies a construct
> and defines a label for it. Nowhere does it permit that label to refer
> to anything else. We aren't talking about free prose here, we are talking
> about a standards document.
> >If that was there intent they could have said:
> > A null pointer constant is an integral constant expression
> > with the value 0, or such an expression cast to type void *.
> That is another way of saying the same thing.
No it is *not*. They have two very different meanings.
> >That would have clearly left no room for anything else to be called a
> >null pointer constant. The way they *actually* worded it, regardless of
> >any part being in italics, *does* appear to leave room for additional
> >constructs to ba called null pointer constants.
> There is no room for anything else as things stand. The only difference
> is in approach. The standard defines a construct and then gives it a label.
> You want to define the label and then specify what it means. The overall
> effect is the same.
Logically the two are not the same:
Consider:
A flat finned creature with two eyes on one side is called a fish.
Is that a correct statement? Does it preclude anything else from being
called a fish?
A fish is a flat finned creature with two eyse on one side.
Is that a correct statement? According to you logic the two statements
are semantically the same. Yet clearly the second statement is false.
The two statements are quite different in their meaning and semantic
content.
The second does not leave room for anything else to be defined as a
fish. The first certainly does.
> >> If we define an rational number as one which may be expressed as the
> >> ratio of two integers, are you going to claim that sqrt(2) may be
> >> irrational since we haven't said that only numbers which can be
> >> expressed as the ratio of two integers are rational?
> >Certainly sgrt(2) is not a rational number! This is exactly the tack
> >you seem to be taking with respect to the standard. Logically, if you
> >define a rational number as above, then you are precluding all numbers
> >that cannot be expressed as a ration of two integers as rational, Pi,
> >the square root of two are both examples of numbers that cannot be
> >expressed as a ratio of two integers. The standard did not define a
> >null pointer constant as an integral constant expression having a value
> >of zero, it simply stated (or at least the cited passage) that this
> >integer 0 is *called* a null pointer constant. That certainly does not
> >exclude anything else from being *called* a null pointer constant.
> "A number that can be expressed as the ratio of 2 integers is called a
> rational number".
> Are you suggesting that this permits sqrt(2) to be called a rational number?
Your definition does exaclty that. Which is why it is wrong. The
proper definition of a rational number is:
A rational number is a number that can be expressed as a ratio of two
integers.
BTW, are you suggesting that if I say:
An enclosed vehicle with an internal combustion engine and four wheels
is called an automobile.
That my statement precludes a six wheeled vehicle or a vehicle powered
by steam or electricity from being called an automobile
> >Assuming that the cited passage is the primary reference to null pointer
> >constants, there is no *definition*. The cited passage does *not*
> >define a null pointer constant, it only provides an example of a null
> >pointer constant. Is there another passage in the standard that *does*
> >define a null pointer constant? If so, please cite that passage.
> The passage most certainly does define a null pointer constant, which is
> emphasised by the fact that the term is italicised.
In that case, the drafters chose extremely poor phraseology. I do not
doubt that their intent was to do as you suggest, I bow to your superior
knowledge of the Standard. I simply state that the passage cited does
not do this. The cited passage is logically ambiguous. I would suggest
that there is another passage that makes this one clear and that the
other passage was not cited.
Mark Halvin
Alicia Carla Longstreet <ca...@ici.net> writes:
>Mark Halvin wrote:
>> Alicia Carla Longstreet <ca...@ici.net> writes:
>> >> >> |> Steve Summit wrote:
>> >
>> >> >> |> > But the compiler is still bound by the definition of
>> >> >> |> > null pointer constant in section 3.2.2.3/6.2.2.3:
>> >
>> >> >> |> > An integral constant expression with the value 0,
>> >> >> |> > or such an expression cast to type void *, is called
>> >> >> |> > a null pointer constant.
~~~~~~~~~~~~~~~~~~~~~
>If it was the drafters intent to specify a single possible definition on
>a null pointer constant with the cited passage, then they made and
>*extremely* poor choice of phraseology.
Alicia, that may or may not be true. The point is that the section that
was quoted consists entirely of definitions of terms. The phrase "null
pointer constant" is in italics -- indicating that this is THE definition
of a null pointer constant, not _A_ definition of a null pointer constant.
By implication (*), there are no others.
(*) In the standard -- not necessarily regular English! :-)
As you 've said numerous times yourself, you have to understand the
context of a statement to understand its meaning.
> A language description must, of
>a necessity, use very precise language. Further, when reading a
>language definition one must be careful to read *exactly* what is
>written and nothing more.
It was written by committee. One of the reasons I was asking before if
you'd actually _read_ the document. It has a characteristic style all its
own.
>If they chose language with leaves something
>open to interpretation there is one of three possibilities 1) They
>intended to leave it open to interpretation (presumably, to allow of the
>needs of different interpretations)
That is simply not done. If that's the effect, it's a defect. Semantics
that are left "open to interpretation" are called Implementation Defined,
and they are enumerated.
> 2) There is some other passage that
>removes the ambiguity,
I couldn't find any.
> 3) They just made a really stupid mistake in
>their choice of langauge.
Entirely possible. Or you could simply be being obtuse. ;-)
>> Remember, this is not literature -- it's a standards document.
>Yes, literature is allowed a lot of freedom with its use of langauge.
>Literature not only can afford ambiguity, it often thrives on it. A
>Standards Document *must* have very precise language. This of course
>merely serves to bolster my argument.
But why is this an "argument"? You took a position that -- while not in
any way ridiculous -- was different than the rest of us who had read the
same section in the document. You were asked to explain, and next thing
you're accusing everybody here of having inferior language skills.
Taken out of context, the paragraph may seem ambiguous to you. It may very
well be ambiguous, and subject to clarification. If you feel that
passionately about it, write a Defect Report.
btw, would you say "precise language" is "emotionally neutral"?
>> they
>> *could* have said, "An implementation may also define other null pointer
>> constants.", but just decided not to. Fine, but why do you think that?
>The could have said "A null pointer constant is an integral constant
>expression having a value of zero, or such an expression cast to type
>void *."
Huh? How is that different from, "An integral constant expression with the
value 0, or such an expression cast to void* is called a null pointer
constant."? I honestly have no clue as to why you see these two sentences
as having different meanings.
> Then there would have been no ambiguity. It would be clear
>that this is the *only* possible null pointer constant.
Why?
"A white horse-like animal with stripes is called a zebra."
"A zebra is a white horse-like animal with stripes."
These really mean different things?
> Now if such a
>small change in wording would have such a dramatic impact on meaning.
>Why do *you* think that they chose that particular wording?
What dramatic impact? This is Orwellian!
>> And what "emotional content"? It's a LANGUAGE SPECIFICATION, remember.
>All words have an emotional content, some more than others. Simply
>because it is a scientific, mathamatical or other document does not
>change that. Anybody who is writing such a document and does not make
>ever effort to use emtionally neutral words is being foolish.
But that's just the way it is!
> BTW, The
>Standards Committee was very careful to use emotionally neutral words
>and phrases. This can not be by accident. It is apparent that the
>drafters of the standard was aware of this.
Exactly. It is written in a very characteristic style. You can usually
detect a quotation from the standard by its style alone.
--
---
Mark....@nyu.edu
Peter Seebach
In article <64085l$1v4$1...@helios.crest.nt.com>,
Kaz Kylheku <k...@helios.crest.nt.com> wrote:
[I said]
>>Indeed; the possibility of other integers converting to null pointers
>>does not make them null pointer constants.
>Why not?
Because that's not what the standard defines as a null pointer constant.
>I would say that the following quote is relevant
> 6.4 Constant expressions
> [ snip ]
> An implementation may accept other forms of constant expressions.
That widens the scope of things an implementation may choose to consider
to be a "constant integer expression equal to zero". So, perhaps an
implementation would be allowed to accept
const int __null__ = 0;
....
#define NULL __null__;
because the implementation chooses to accept 'const int' as being a constant,
in some cases.
It still has to follow the rules for null pointer constants.
>Of course, a portable program may not use these ways of writing a null pointer,
>but that's a different issue from whether or not such an implementation
>is conforming.
The implementation would be non-conforming, because the requirement of
zeroness is not in 'constant expressions' but in the definition of
the null pointer constant.
Douglas A. Gwyn
In article <01bceb2f$b4369ec0$0376420c@default>,
"Jack Klein" <jack...@worldnet.att.net> wrote:
>> This is *the* definition of a null pointer constant; there
>aren't
>> any others. So while it might work, in a particular
>environment,
>> for a compiler's copy of <stddef.h> to contain something like
>> #define NULL 06000
>> , and while a conforming program might not be able to tell the
>> difference, such a definition would clearly be contrary to the
>> requirements of the Standard.
>I hate to argue with the only person who's book on C I own and
>have corresponded with, "implementation-defined" means exactly
>that. An implementation can define ANYTHING it wants as long as
>it documents it and it doesn't break conforming programs.
That's not how the C committee has viewed it; we're planning to
clarify this in C9x with new wording to the effect that
"implementation-defined behavior" = "unspecified" +
the_choice_is_documented.
We also have new words to make it clearer that "unspecified"
means merely a situation for which there are multiple correct
implementation alternatives. None of this gives a conforming
implementation latitude to do anything beyond making one of
the choices allowed by the specifications in the standard.
The problem with
#define NULL 06000
is that the violation of the specification is detectable by a
strictly conforming program that stringizes the expanded macro
and examines the contents, taking different action depending on
whether the definition has the form required for a null pointer
constant or not, which alas 06000 does not. Nobody says that
this is a terribly practical thing to do, but it serves to
prove the point.
Douglas A. Gwyn
In article <64085l$1v4$1...@helios.crest.nt.com>,
k...@helios.crest.nt.com (Kaz Kylheku) wrote:
>Why not? I would say that the following quote is relevant
> 6.4 Constant expressions
> [ snip ]
> An implementation may accept other forms of constant expressions.
Nope, you're not talking about another *form*.
Also, it still doesn't meet the requirements for "null pointer constant".
>In fact, on some implementation, these may be the more ``natural'' forms for
>a null pointer to have, and zeros are accepted as special cases due to
>the standard's requirement. Indeed, any implementation which uses a non-zero
>bit pattern for a null pointer, and which does not map the integer zero
>to that bit pattern, must implement special case treatment for 0, (void *) 0
>and (T *) 0, and bypass the ordinary mapping.
It is certainly a quirk of C that what appears to be a pointer cast of
the integer value zero is not in fact the natural conversion of the integer
value 0 to a pointer. It makes it tricky to write system code where a true
pointer to something with address 0 (in native machine terms) is needed.
I recommend to any future language designer that they not repeat this
mistake, but rather, if they intend to have an "exceptional" value for a
pointer at all, use some distinctive syntax such as "nil" for it.
Alicia Carla Longstreet
> >representation one way or another as to whether or not this is the only
> >null pointer constant or whether anything else is or can be called a
> >null pointer constant. Don't read more into words than are there, for
> >the same reason that you should not read less into words than are there.
> This is a LANGUAGE DESCRIPTION! It is intended to be a precise
> specification for the behavior and syntax of C. Are you telling me that
> the committee decided to just leave this up to interpretation? As I said
> before, you may be correct, but I'd feel much more confident if I were you
> if I could supply another example where the standard's language was
> similarly vague.
If it was the drafters intent to specify a single possible definition on
a null pointer constant with the cited passage, then they made and
*extremely* poor choice of phraseology. A language description must, of
a necessity, use very precise language. Further, when reading a
language definition one must be careful to read *exactly* what is
written and nothing more. If they chose language with leaves something
open to interpretation there is one of three possibilities 1) They
intended to leave it open to interpretation (presumably, to allow of the
needs of different interpretations) 2) There is some other passage that
removes the ambiguity, 3) They just made a really stupid mistake in
their choice of langauge.
> Remember, this is not literature -- it's a standards document.
Yes, literature is allowed a lot of freedom with its use of langauge.
Literature not only can afford ambiguity, it often thrives on it. A
Standards Document *must* have very precise language. This of course
merely serves to bolster my argument.
> >> ...to proclaiming yourself capable of interpreting the intent of the ANSI
> >> C Committee.
> >Of course I am capable of interpreting the intent of the ANSI C
> >committee, as are you, and anybody else who is capable of reading the
> >standard.
> So you have read the standard? Great, where else do they leave something
> so fundamental open to such interpretation?
Read the standard and find out.
> > Unless you assume that they did not outline their intent in
> >the words of the standard but just threw out any old thing.
> No, that's what *you* seem to think. You seem to be saying that they
> *could* have said, "An implementation may also define other null pointer
> constants.", but just decided not to. Fine, but why do you think that?
The could have said "A null pointer constant is an integral constant
expression having a value of zero, or such an expression cast to type
void *." Then there would have been no ambiguity. It would be clear
that this is the *only* possible null pointer constant. Now if such a
small change in wording would have such a dramatic impact on meaning.
Why do *you* think that they chose that particular wording?
> >> And I still don't think you've even seen a copy of the standard
> >> yourself. Do correct me if I'm wrong on that point, because if you
> >> HAVE read the standard -- and are still as willfully ignorant as you've
> >> been demonstrating -- you need to write a book annotating it; it could make
> >> a silk purse out of Herbert Schildt's ear.
> >Maybe you should read the standard, or take a course in English and
> >reread the standard. You have shown a great tendency to read you own
> >private meaning into everything you read or say. You ignore semantics,
> >you ignore emotional content, you simply assume that everybody will
> >understand *exactly* what you mean. Then you deride me for actually
> >posting what I believe or want a term to mean, in order to facilitate
> >communication.
> I should be writing that to you. Who is famous for reinventing meanings
> for words?
Actually, I am famous for having the nerve to actually putting my
definitions in print, and then asking for alternatives.
> And what "emotional content"? It's a LANGUAGE SPECIFICATION, remember.
All words have an emotional content, some more than others. Simply
because it is a scientific, mathamatical or other document does not
change that. Anybody who is writing such a document and does not make
ever effort to use emtionally neutral words is being foolish. BTW, The
Standards Committee was very careful to use emotionally neutral words
and phrases. This can not be by accident. It is apparent that the
drafters of the standard was aware of this.
--
By speaking, by thinking, we undertake to clarify things,
and that forces us to exacerbate them, dislocate them,
schematize them. Every concept is in itself an exaggeration.
José Ortega y Gasset
Mark Halvin
Alicia Carla Longstreet <ca...@ici.net> writes:
>Logically the two are not the same:
>Consider:
>A flat finned creature with two eyes on one side is called a fish.
>Is that a correct statement? Does it preclude anything else from being
>called a fish?
>A fish is a flat finned creature with two eyse on one side.
>Is that a correct statement? According to you logic the two statements
>are semantically the same. Yet clearly the second statement is false.
>The two statements are quite different in their meaning and semantic
>content.
In ordinary English, yes; but not in the standard. That is the way terms
are defined therein. It is an enumeration of definitions. The term "null
pointer constant" is in italics; this is _the_ description of the
syntactic "null pointer constant".
Besides, for the standard to define a term in an way analogous to your
example would be silly, and I think you know that.
>The second does not leave room for anything else to be defined as a
>fish. The first certainly does.
Why would the term be defined, yet not _fully_ defined?
Mr. Kirby (I believe) said:
>> The passage most certainly does define a null pointer constant, which is
>> emphasised by the fact that the term is italicised.
>In that case, the drafters chose extremely poor phraseology. I do not
>doubt that their intent was to do as you suggest, I bow to your superior
>knowledge of the Standard.
You don't have to do that. Just buy yourself a copy and read it. There's
no shame in not having done so; but there is embarassment in trying to
interpret something you haven't read yourself, in context.
> The cited passage is logically ambiguous.
It's not a logic problem -- it's a definition of a term.
> I would suggest
>that there is another passage that makes this one clear and that the
>other passage was not cited.
But where would that BE? Oh, you mean the _other_ definition of the term?
;-)
--
---
Mark....@nyu.edu
Mark Halvin
Alicia Carla Longstreet <ca...@ici.net> writes:
>Michael Rubenstein wrote:
>> That is the definition of a null pointer constant. The term "null
>> pointer constant" is in italics. That means it is the definition of
>> the term. In the standard, putting a term in italics means that the
>> term is being defined. In most places (subclause 3 being the only
>> exception I know off hand) the standard indicates a definition only by
>> putting the term in italics.
>Okay, so they made a very poor choice of phraseology, rather silly of
>them wasn't it. I might suggest that the C9X committee correct this poor
>phraseology and eliminate the ambiguity,
Write that Defect Report!
> especially since there are
>mediums where the italics may be lost.
Not really. The standard is only available in print, as far as I know.
>BTW, what do you do on an architecture where there is an actual memory
>address location 0? How would the implementation address it?
Being that you've got a BIG sig with a reference to the comp.lang.c FAQ,
I'm presuming this is a troll. On the off-chance it's not:
> 5.5: How should NULL be defined on a machine which uses a nonzero bit
> pattern as the internal representation of a null pointer?
>
> A: The same as on any other machine: as 0 (or ((void *)0)).
>
> Whenever a programmer requests a null pointer, either by writing
> "0" or "NULL," it is the compiler's responsibility to generate
> whatever bit pattern the machine uses for that null pointer.
> Therefore, #defining NULL as 0 on a machine for which internal
> null pointers are nonzero is as valid as on any other: the
> compiler must always be able to generate the machine's correct
> null pointers in response to unadorned 0's seen in pointer
> contexts. See also questions 5.2, 5.10, and 5.17.
>
> References: ANSI Sec. 4.1.5; ISO Sec. 7.1.6; Rationale
> Sec. 4.1.5.
IOW, using 0 (or NULL) in a "pointer context" causes the compiler to
_generate_ a null pointer -- not set all the bits off in the pointer. It
is possible for there to be _different_ values for various null pointer
types, in fact. So, there is nothing to prevent this:
#include <stdio.h>
#include <assert.h>
int main()
{
int n;
int* const ip = &n;
assert(ip != 0); /* it'll never happen */
printf("%lu", (unsigned long)&ip);
return 0;
}
from printing "0". The address of n could even be represented by
all-bits-off-zero in the int* -- it's the comparison to 0 in the assert
that will have cause the compiler to generate a null int* value, which is
then used in the comparison to ip.
(Of course, there is nothing to prevent the machine from [insert something
silly or scary here], since the code evokes Undefined Behavior.)
--
---
Mark....@nyu.edu
Michael Rubenstein
>Michael Rubenstein wrote:
>
>> That is the definition of a null pointer constant. The term "null
>> pointer constant" is in italics. That means it is the definition of
>> the term. In the standard, putting a term in italics means that the
>> term is being defined. In most places (subclause 3 being the only
>> exception I know off hand) the standard indicates a definition only by
>> putting the term in italics.
>
>Okay, so they made a very poor choice of phraseology, rather silly of
>them wasn't it. I might suggest that the C9X committee correct this poor
>phraseology and eliminate the ambiguity, especially since there are
>mediums where the italics may be lost.
>
>BTW, what do you do on an architecture where there is an actual memory
>address location 0? How would the implementation address it?
Only you seem to have any problem with the wording. A definition is
always exhaustive, by definition.
The Random House Unabridged dictionary defines "definition" as
2. the formal statement of the meaning or significance of a
word, phrase, etc.
Thus a when the standard defines a null pointer constant as
An integral constant expression with the value 0, or such an
expression cast to type void *, is called a null pointer
constant.
they are saying that the term "null pointer constant" means "an
integral constant expression with the value 0, or such an expression
cast to type void *."
Compare this with Hardy and Wright defining the integers:
The numbers
..., -3, -2, -1, 0, 1, 2, ...
are called the rational integers, or simply the integers
Note that this does not imply that (void*) 0xffffffff is not a null
pointer. In fact, as I read the standard, an implementaion could
convert every integer to the null pointer. But (void*) oxffffffff is
not a null pointer constant and so cannot be the definition of NULL.
What does this have to do with addressing location 0? The standard
does not say that the internal representation of a null pointer is
binary 0. When one writes
int* p = 0;
the binary representation 0xffffffff could be stored in p. When one
compares p == 0, the internal representation could be compared to
0xffffffff.
Of course this means that one cannot use a constant 0 to assign the
location at 0 to a pointer, but the standard doesn't require that one
can create every (or, for that matter, any) pointer by converting an
integer.
If it were considered necessary to give the programmer the ability to
convert an integer to the pointer that refers to location 0, either
some other number could be made to convert to it or the implementation
could require that an expression with value 0 that is not an integral
constant expression be used. For example, one might write
int* p = 0, 0;
Or, of course, the implementation could simply arrange things so that
no object could be allocated at location 0. This is very common
anyways. The PC has a location 0, but it is not available to a C
program.
Michael M Rubenstein
Daniel Griffie
Excerpts from netnews.comp.lang.c++: 8-Nov-97 Re: null pointer constants
.. Mark Hal...@acf5.nyu.edu (4821)
> "A white horse-like animal with stripes is called a zebra."
> "A zebra is a white horse-like animal with stripes."
> These really mean different things?
Indeed they do. The first statement does not preclude other things from
being a zebra. The logical equivalent is saying that { white horse
w/stripes} is a subset of Zebra. This in no way implies that Zebra =
{white horse w/stripes }. The second statement precisely defines what a
zebra is. Ie. Zebra = {white horse w/stripes }.
Similiarly the passage taken out of context does not preclude other
things from being null pointers.
Daniel Griffie
dgri...@andrew.cmu.edu
Douglas A. Gwyn
In article <346471...@ici.net>,
>> When the standard says that a null pointer constant is an integral
>> constant expression with the value 0, or such a type cast to type
>> void *, it means that it is "always" that, *in a conforming
>> implementation*. Nothing can be said about implementations that do
>> not conform to all the requirements of the standard, other that
>> they do not conform to all the requirements of the standard.
>a NULL pointer constant is an integral expression with a zero value. It
>null pointer constant.
No, I'm not twisting the words around!
I chose the words in my response to address the particular claim that
the standard didn't mean *all* null pointer constants had to have one
of the specified forms since the standard did not say "always".
On the other hand, you're certainly twisting *something* around, by
capitalizing "null" in "null pointer constant". The NULL macro that
is defined in several of the standard headers has to be defined (by a
conforming implementation) as a null pointer constant, and every
conforming implementation is required to document its exact definition.
But the implementation definition of the NULL macro is not the only
form a null pointer constant can take in a strictly conforming program;
those are described in C89 subclause 6.2.2.3, which says what I said it
did. That *defines* the technical term "null pointer constant".
A point that people seem to miss is that "null pointer constant" is a
*contextual* notion. The same lexical string can denote a null pointer
constant in some contexts but not in others. In a context where the
standard requires there to be a null pointer constant, a strictly
conforming program must use one of the forms specified in 6.2.2.3;
and when the implementation is required to define NULL as a null pointer
constant, it must be defined as one of the forms specified in 6.2.2.3.
>Those two statments have *very* different meanings. The first, yours,
>would in fact be intrpreted to mean that a NULL pointer constant is
>*always* and intregral expression with a value of 0, the second (and the
>quote from the Standard) merely specifies that an intregral expression
>with a value of 0 is, and possibly one of exveral expressions, called a
>NULL pointer constant.
I don't know how you could possible "interpret" my very clear enunciation
of the two alternative forms (with words taken straight from the standard)
as an enunciation of just one form. The standard does not say "possibly
one of several expressions"; it says what I said it did.
>If the standard had worded it as you did then I would agree that the
>standard did not intend to leave room for anything else to be called a
>null pointer constant. Based on the passage cited by Jack Klien one
>would have to conclude that the standard left room for other constructs
>that can be called null pointer constants. Now if you can find another
>passage in the standard to support you position.
I'm telling you how to understand the relevant wording in the standard,
which I helped write. Now you should do your part, and work to understand.
Maybe you should obtain a copy of the C standard so you can look these
things up for yourself; otherwise you can only argue from hearsay and
ignorance.
The strange thing is, everything I have been saying about this supports
your original point about the abuse of the NULL macro.
Douglas A. Gwyn
In article <346476...@ici.net>,
> An integral constant expression with the value 0,
> or such an expression cast to type void *, is called
> a null pointer constant.
>It seems clear enough, it states that an integral constant expression
>with the value 0 is call a null pointer constant. It makes no
>representation one way or another as t o whether or not this is the only
>null pointer constant or wheterh anything else is or can be called a
>null pointer constant. Don't read more into words than are there, for
>the same reason that you should not read less into words than are there.
Because you feel comfortable letting others read the standard *for* you,
you missed the fact that in the original text of the standard, "null
pointer constant" is *italicized* in the above -- it is being *defined*
by that sentence. And there is no logical alternative to taking that
as the definition of "null pointer constant", since there is nothing
else in the standard that even comes close to being interpretable as a
definition of the term. Furthermore, the Index gives only that one
reference (6.2.2.3) for the term, *and* the reference is in bold face,
which denotes the primary specification for the term.
>You have no actually understood anything I have said.
The fact that Mark disagreed with you and with your epistemology does
not necessarily mean that he didn't understand what you said.
Mark Halvin
Daniel Griffie <dgri...@andrew.cmu.edu> writes:
>Excerpts from netnews.comp.lang.c++: 8-Nov-97 Re: null pointer constants
>.. Mark Hal...@acf5.nyu.edu (4821)
>> "A white horse-like animal with stripes is called a zebra."
>> "A zebra is a white horse-like animal with stripes."
>> These really mean different things?
>Indeed they do. The first statement does not preclude other things from
>being a zebra. The logical equivalent is saying that { white horse
>w/stripes} is a subset of Zebra. This in no way implies that Zebra =
>{white horse w/stripes }. The second statement precisely defines what a
>zebra is. Ie. Zebra = {white horse w/stripes }.
Let me clarify my point -- I may not have been explicit enough in
presenting my example. If this were an entry in a list of definitions of
terms -- "zebra" being the entity being described in this case -- do you
seriously contend that the two sentences are not equivilant? I'm not
trying to be difficult! :-) These are declarative statements of fact,
not logical operators! :-)
Granted, it may not be in a form that quotes well out of context, but it's
a common idiom in the standard - i.e., "A {definition of the term} is
called a {term, in italics}."
>Similiarly the passage taken out of context does not preclude other
>things from being null pointers.
Yes, and maybe that's the lesson here -- The standard apparantly doesn't
quote well out of context! It's all controlled by a big language-lawyer
racket, anyway. ;-D
"First thing we do, is kill all the language lawyers.", Wm Shakespeare
--
---
Mark....@nyu.edu
Douglas A. Gwyn
In article <3464FE...@ici.net>,
>address location 0? How would the implementation address it?
The implementation has no problem; it's "how would a programmer write
code that accesses the contents at address 0?" The simple answer is,
it's more difficult than merely writing (type *)0, because that has
to be taken as denoting a null pointer, which must be distinct from
any pointer to an accessible object. However, it can be done; maybe
this would make a good contest.
Douglas A. Gwyn
In article <3464F8...@ici.net>,
>expression having a value of zero, or such an expression cast to type
>void *." Then there would have been no ambiguity. It would be clear
>that this is the *only* possible null pointer constant. Now if such a
>small change in wording would have such a dramatic impact on meaning.
>Why do *you* think that they chose that particular wording?
We chose that wording because it would be WRONG to use your wording,
which *equates* two things that actually are not always the same.
The requirement that a "null pointer constant" be used appears only
in certain contexts; in those contexts "0" (for example) can be used,
but there are other contexts in which "0" can be used that are not
null pointer contexts (and in which "(void*)0" must *not* be used).
The only use for the term "null pointer constant" is where we *call*
something a "null pointer constant" in the standard, at which point
any reader who does not recall what that means will use the Index to
find 6.2.2.3, where the exact meaning of that term is specified.
I must say that nobody who has actually used the C standard directly
has had a problem with this definition, only people like you who are
unfamiliar with the style, terminology, and content of the standard
yet insist on telling others what it means. I don't think, if this
were brought to the floor in a committee meeting, that it would be
taken as an indication that the wording needs to be changed.
Alicia Carla Longstreet
> >Consider:
> >A flat finned creature with two eyes on one side is called a fish.
>
> >Is that a correct statement? Does it preclude anything else from being
> >called a fish?
>
> >A fish is a flat finned creature with two eyse on one side.
>
> >Is that a correct statement? According to you logic the two statements
> >are semantically the same. Yet clearly the second statement is false.
>
> >The two statements are quite different in their meaning and semantic
> >content.
> are defined therein. It is an enumeration of definitions. The term "null
> pointer constant" is in italics; this is _the_ description of the
> syntactic "null pointer constant".
Ah, now we have gotten to the root of the problem. The C Programming
Standard is not written in English, but rather some English like
langauge!
> Besides, for the standard to define a term in an way analogous to your
> example would be silly, and I think you know that.
You mean, that the standard method of defining a term is silly:
a {term being defined} is {definition}
Look in *any* dictionary, any text book, and glossary. This common
artifice for defining terms was not arbitrary. It is done this way
because:
a {definition} is called a {term being defined)
is ambiguous and is logically *not* a definition.
> >The second does not leave room for anything else to be defined as a
> >fish. The first certainly does.
> Why would the term be defined, yet not _fully_ defined?
Possibly becasue no complete definition was known. When the standard
was drafted, we knew of many possible architectures and many theoretical
architectures. The language had to be able to work on any existing
architecture and most theoretical architectures. So ther, presumably,
drafted a language defintion that would continue to be functional on new
and possibly very different architectures.
> Mr. Kirby (I believe) said:
> >> The passage most certainly does define a null pointer constant, which is
> >> emphasised by the fact that the term is italicised.
> >In that case, the drafters chose extremely poor phraseology. I do not
> >doubt that their intent was to do as you suggest, I bow to your superior
> >knowledge of the Standard.
> You don't have to do that. Just buy yourself a copy and read it. There's
> no shame in not having done so; but there is embarassment in trying to
> interpret something you haven't read yourself, in context.
> > The cited passage is logically ambiguous.
> It's not a logic problem -- it's a definition of a term.
Linguistically speaking, it is not a complete definition, rather it is a
definition by example. Definitions by example are always ambiguous, and
will remain so. The Standard uses definition by example. This may be
good because it gives the standard flexibility.
In this case, if an implementation needed to address an object at
location 0. It could define a null pointer as (as required)
#define NULL (void *)0
yet (through magic) insure that a NULL pointer never actually referenced
any addressable memory.
If I happend to know what the actual value was, I might sacrifice
portability for efficiency and use the real value as my null pointer
constant. Probably I will never do such a thing (if fact, I have a
better chance of winning the lottery - I never buy any tickets to it),
but I really prefer not to lose the flexibility.
Which brings us full circle, and the two points I hope have been made in
this thread.
double myNum = NULL;
is bad programming practice and, I believe, is undefined behavior
(assigning a pointer to a double).
and, some of us just love to be language lawyers :-) (AKA Devils
Advocate).
Mark Halvin
Alicia Carla Longstreet <ca...@ici.net> writes:
>In this case, if an implementation needed to address an object at
>location 0. It could define a null pointer as (as required)
>#define NULL (void *)0
>yet (through magic) insure that a NULL pointer never actually referenced
>any addressable memory.
But through what magic? The standard simply requires the implementation to
treat (void*)0 and 0 -- when compared with or assigned to a pointer type
-- as a "null pointer constant". Then a null pointer (of the appropriate
type) is generated. Remember, many programmers never use NULL, so your
magic wouldn't work! <g>
>If I happend to know what the actual value was, I might sacrifice
>portability for efficiency and use the real value as my null pointer
>constant.
Exactly. Your code would then be non-conforming, that's all. Not bad. Just
non-conforming. Big Deal!
> Probably I will never do such a thing (if fact, I have a
>better chance of winning the lottery - I never buy any tickets to it),
>but I really prefer not to lose the flexibility.
You haven't lost a darn thing! Any time you assign an integral value to a
pointer -- or compare an integral value to a pointer -- you evoke
Undefined Behavior, unless it's an integeral constant 0 or such a value
cast to a void*. So what? You can define main() to return void, too. And
maybe that will be more "efficient" on your system. Nothing stops you from
doing that, does it?
>Which brings us full circle, and the two points I hope have been made in
>this thread.
>double myNum = NULL;
>is bad programming practice and, I believe, is undefined behavior
>(assigning a pointer to a double).
Yes, and yes.
--
---
Mark....@nyu.edu
Richard Stamp
In article <346630...@ici.net>,
>Standard is not written in English, but rather some English like
>langauge!
Yes Alicia, you have precisely identified the problem. The Standard
isn't written in the type of English we'd use in day-to-day conversation
and it's foolish to argue as if it were.
There are plenty of other examples where the text says something "is called
<phrase-in-italics>" and it's quite clear that these are definitions.
Other times, a phrase is defined just in passing, by placing it in italics
inside brackets after its definition. Really, if you looked at more of
the context, I think you'd see there's little ambiguity.
In any case, authoritative posters have explained what the intended meaning
of that phrase is, so it would be nice if we could give it a rest now.
(Followups set; this has nothing to do with C++.)
Cheers,
Richard
--
Richard Stamp
Churchill College, Cambridge
Richard Stamp
In article <645dmf$o...@acf5.nyu.edu>, Mark Halvin <mh...@acf5.nyu.edu> wrote:
>
>Any time you assign an integral value to a
>pointer -- or compare an integral value to a pointer -- you evoke
>Undefined Behavior
Isn't it actually a constraint violation (if you don't use a cast)
or an implementation defined result (if you do)?
>unless it's an integeral constant 0 or such a value cast to a void*.
Agreed.
Mark Halvin
rg...@cam.ac.uk (Richard Stamp) writes:
>In article <645dmf$o...@acf5.nyu.edu>, Mark Halvin <mh...@acf5.nyu.edu> wrote:
>>
>>Any time you assign an integral value to a
>>pointer -- or compare an integral value to a pointer -- you evoke
>>Undefined Behavior
>Isn't it actually a constraint violation (if you don't use a cast)
>or an implementation defined result (if you do)?
Yes, you are correct -- it is Implementation Defined, not Undefined
behavior. Sorry about that!
--
---
Mark....@nyu.edu
Craig Franck
Alas, the annotation page from ol' Herb's book is bare. :-(
(I think you were the audience he had in mind with his effort at
annotating the standard.)
>Every concept is in itself an exaggeration.
> José Ortega y Gasset
You must have an interesting library. :-)
Life is the art of drawing sufficient conclusions from insufficient
premises. -- Samuel Butler
All our reasoning ends in surrender to feeling. -- Blaise Pascal
An exaggeration is a truth that has lost its temper.
-- Kahlil Gibran
--
Craig
clfr...@worldnet.att.net
Manchester, NH
I try to take one day at a time, but sometimes several
days attack me at once. -- Ashleigh Brilliant
Alicia Carla Longstreet
Mark Halvin wrote:
> Daniel Griffie <dgri...@andrew.cmu.edu> writes:
> >.. Mark Hal...@acf5.nyu.edu (4821)
> >> "A white horse-like animal with stripes is called a zebra."
> >> "A zebra is a white horse-like animal with stripes."
> >> These really mean different things?
> >Indeed they do. The first statement does not preclude other things from
> >being a zebra. The logical equivalent is saying that { white horse
> >w/stripes} is a subset of Zebra. This in no way implies that Zebra =
> >{white horse w/stripes }. The second statement precisely defines what a
> >zebra is. Ie. Zebra = {white horse w/stripes }.
> Let me clarify my point -- I may not have been explicit enough in
> presenting my example. If this were an entry in a list of definitions of
> terms -- "zebra" being the entity being described in this case -- do you
> seriously contend that the two sentences are not equivilant? I'm not
> trying to be difficult! :-) These are declarative statements of fact,
> not logical operators! :-)
I *seeriously* contend that the two statments are logically and
factually different. It is quite apparent that the memebers of the
committee were not 'language lawyers'. I just hope they never try to sue
somebody for claiming that their C compiler is ANSI conforming just
because it also uses 0xffffffff as a null pointer constant. Becasue the
Judge that examines the standard is going to assume that each and every
statement stands on it own and the simple fact that it happens to appear
with a group of definitions is irrelevant (at least as far as a Judge
will be concerned).
> Granted, it may not be in a form that quotes well out of context, but it's
> a common idiom in the standard - i.e., "A {definition of the term} is
> called a {term, in italics}."
That is most unfortunate. I certainly hope that someone on the C9X
committee see this and understands how poor this langauge is. Most
technical documents that I deal with (non-technical ones as well) use
the following atifice to define terms:
{Term to be defined} is {definition};
Look in any dictionary and you will note that this is the accepted
method of defining terms. There is a reason for this, it leaves no room
for ambiguity.
> >Similiarly the passage taken out of context does not preclude other
> >things from being null pointers.
> Yes, and maybe that's the lesson here -- The standard apparantly doesn't
> quote well out of context! It's all controlled by a big language-lawyer
> racket, anyway. ;-D
> "First thing we do, is kill all the language lawyers.", Wm Shakespeare
You better kill the other lawyers first, they are the ones who will put
you in jail for killing the langauge lawyers.
Craig Franck
>
>> Daniel Griffie <dgri...@andrew.cmu.edu> writes:
>
>> >.. Mark Hal...@acf5.nyu.edu (4821)
>> >> "A white horse-like animal with stripes is called a zebra."
>> >> "A zebra is a white horse-like animal with stripes."
>
>> >> These really mean different things?
>
>> >Indeed they do. The first statement does not preclude other things from
>> >being a zebra. The logical equivalent is saying that { white horse
>> >w/stripes} is a subset of Zebra. This in no way implies that Zebra =
>> >{white horse w/stripes }. The second statement precisely defines what a
>> >zebra is. Ie. Zebra = {white horse w/stripes }.
>
>> Let me clarify my point -- I may not have been explicit enough in
>> presenting my example. If this were an entry in a list of definitions of
>> terms -- "zebra" being the entity being described in this case -- do you
>> seriously contend that the two sentences are not equivilant? I'm not
>> trying to be difficult! :-) These are declarative statements of fact,
>> not logical operators! :-)
>
>I *seeriously* contend that the two statments are logically and
>factually different.
I tend to agree with you on this, but... "A <I>meal</I> is a
Double Quarter Pounder with cheese served at McDonald's." A more
formal definition may then state "nothing else is a meal". Is a
Big Mac a meal? No. A quote from 5.2.1
A byte with all bits set to 0, called the <I>null character</I>,
shall exist in the basic execution character set; it is used to
terminate a character string literal.
Only a byte with all bits set to 0 is the null character; this
definition, by your reasoning, doesn't preclude a byte with all
bits set to 1 being a null character -- it's just not the way the
wording of the standard works.
>It is quite apparent that the memebers of the
>committee were not 'language lawyers'. I just hope they never try to sue
>somebody for claiming that their C compiler is ANSI conforming just
>because it also uses 0xffffffff as a null pointer constant. Becasue the
>Judge that examines the standard is going to assume that each and every
>statement stands on it own and the simple fact that it happens to appear
>with a group of definitions is irrelevant (at least as far as a Judge
>will be concerned).
>
>> Granted, it may not be in a form that quotes well out of context, but it's
>> a common idiom in the standard - i.e., "A {definition of the term} is
>> called a {term, in italics}."
>
>That is most unfortunate. I certainly hope that someone on the C9X
>committee see this and understands how poor this langauge is. Most
>technical documents that I deal with (non-technical ones as well) use
>the following atifice to define terms:
>
>{Term to be defined} is {definition};
>
>Look in any dictionary and you will note that this is the accepted
>method of defining terms. There is a reason for this, it leaves no room
>for ambiguity.
The italicized method allows for a more free form approach.
<I>Felicity</I>, my next door neighbors cat...
allows you to define a term with easily identifiable italics and
keep a flowing narrative *at the same time*.
Michael Rubenstein
>a {term being defined} is {definition}
>
>Look in *any* dictionary, any text book, and glossary. This common
>artifice for defining terms was not arbitrary. It is done this way
>because:
>
>a {definition} is called a {term being defined)
>
>is ambiguous and is logically *not* a definition.
OK. I looked in some text books. My degree was in mathematics, so
naturally I am more familiar with texts in that field. I've
surrounded the term being defined with asterisks. In the texts,
these are emhpasized by bold face, italics, or underlining.
H. E. Rose; A course in Number Theory; Clarendon; 1994; ISBN
0-19-853479-5
Each set of phi(m) integers {c1, ..., cphi(m)} whose elements
satisfy
ci != cj (mod m) if i != j, and
(ci, m) = 1 for 1 <= i <= phi(m)
is called a *reduced system of residues* modulo m.
Walter Rudin; Real and Complex Analysis; McGraw-Hill; 1966
A function on a measurable space X whose range consists of
only finitely many points in [0, infinity) will be called a
simple function.
John Kelly; General Topology; D. Van Nostrand; 1955 [I believe this is
now published by Springer-Verlag]
Convergence in the product topology is called *coordinatewise
convergence* or *pointwise convergence*.
Serge Lang; Algebra; Addison-Wesley; 1965
Let S be a set. A mapping
S x S -> S
is sometimes called a *law of composition* (of S into itself).
Its shocking that such prominant mathematicians could be so illogical.
This is even more shocking on a book on mathematical logic:
Elliott Mendelson; Introduction to Mathematical Logic; D. Van
Nostrand; 1964
A sentence (in some natural language like English, or in a
formal theory) which arises from a tautology by substitution
of sentences for all the statement letters, occurrences of the
same sentence being replaced by tthe same sentence, is said to
be *logically true* (according to the propositional calculus).
Apparently, even Goedel was deficient in his understanding of logic.
Kurt Goedel; The Consistency of the Continuum Hyphothesis; Princeton;
1940
The cardinal of a set is called a *cardinal number*.
Michael M Rubenstein
Jos A. Horsmeier
Alicia Carla Longstreet wrote:
> I *seeriously* contend that the two statments are logically and
> factually different. It is quite apparent that the memebers of the
> committee were not 'language lawyers'. I just hope they never try to sue
> somebody for claiming that their C compiler is ANSI conforming just
> because it also uses 0xffffffff as a null pointer constant. Becasue the
> Judge that examines the standard is going to assume that each and every
> statement stands on it own and the simple fact that it happens to appear
> with a group of definitions is irrelevant (at least as far as a Judge
> will be concerned).
Any judge who would act like that overhere in the Netherlands would
be fired on the spot. 'context' and/or 'circumstances' play an important
role ... (and rightly so IMHO)
Jos aka j...@and.nl
Dik T. Winter
In article <346630...@ici.net> ca...@ici.net writes:
> Ah, now we have gotten to the root of the problem. The C Programming
> Standard is not written in English, but rather some English like
> langauge!
Yes, that is it. *All* standards are in standardese because English is
just not precise enough. Similarly all laws are in legalese.
> Look in *any* dictionary, any text book, and glossary. This common
> artifice for defining terms was not arbitrary. It is done this way
> because:
> a {definition} is called a {term being defined)
> is ambiguous and is logically *not* a definition.
This is a fairly common way to write a definition in mathematics.
Admittedly it is not so in natural languages, because they are less
concerned with strict definitions. In mathematics it is *not*
ambiguous and is logically a definition. Let's look at Ahlford's
Complex Analysis (a fairly standard work that is just sitting in
front of me), page 7:
[in the context of complex numbers "a + b.i"]:
The product z.conj(z) = a^2 + b^2 is always positive or zero.
Its nonnegative square root is called the <i>modulus</i> or
<i>absolute value</i> of the complex number z; it is denoted
by |z|.
While (seen as pure English) other values could also be named
the modulus, in mathematics, computer science, standardese and
(I think) legalese, such things are always meant to be exhaustive.
So whenever you use the term modulus, you mean a thing as defined
above.
> In this case, if an implementation needed to address an object at
> location 0. It could define a null pointer as (as required)
> #define NULL (void *)0
> yet (through magic) insure that a NULL pointer never actually referenced
> any addressable memory.
Yup, that is what happens.
> If I happend to know what the actual value was, I might sacrifice
> portability for efficiency and use the real value as my null pointer
> constant.
Can you explain how you get efficiency through this? The magic performed
is most likely compile-time, not run-time!
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/