R
Richard Heathfield
CBFalconer said:
Prove it, solely with reference to ISO/IEC 9899.
Prove it, solely with reference to ISO/IEC 9899.
J
J. Sommers
Whoa! Nitpicking!
Well, what about the following: You have a structure
with fields consisting of (say) integers and pointers (to whatever you
want.) Those pointers had better be initialized to NULL (it is NULL this
time right?) Is it appropriate to use calloc here?
K
Keith Thompson
J. Sommers said:
No. A null pointer is not necessarily represented as all-bits-zero.
J
J. Sommers
Good point. Can you provide examples?
C
Chris Dollin
J. Sommers said:
At least one of the Prime series, I am given to understand.
But in any case it doesn't matter; the Standard doesn't say that null
is all-bits-zero and takes care that it isn't implied by other things
it does say, and so we know that code that makes this assumption isn't
portable and we don't do it.
(Unless we must; I've had no examples myself.)
--
The second Jena user conference! http://hpl.hp.com/conferences/juc2007/
"You're not supposed to /think/ about it, /The Beiderbeck Connection/
you're supposed to say NO!" Jill Swinburn
Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN
J
J. Sommers
Prime Computers is dead isn't it?
Seriously, while I agree as a matter of principle with what is
being said, I don't think that being dogmatic about it is such a good
idea. Alas, not all C code developed out there is meant to be portable.
Which is why (heresy!) I'll carry on using calloc() the way I described
and live unconcerned in the knowledge that if somebody tries to port it
to a Prime computer (sure, tomorrow) they'll have some work to do.
K
Keith Thompson
J. Sommers said:
*Or* you can write code that doesn't make any assumptions about how
pointers are represented. It's not all that difficult.
For example, you can take advantage of the fact that objects with
static storage duration are implicitly initialized to zero, not
necessarily all-bits-zero (pointers are initialized to null,
floating-point objects are initialized to 0.0). Similarly, if an
explicit initializer doesn't provide values for all members of an
object, the remaining members are initialized to zero, converted to
the appropriate type.
Suppose you have a type "struct mystruct" that contains pointer
members.
const struct mystruct mystruct_zero = { 0 };
struct mystruct *ptr = malloc(COUNT * sizeof *ptr);
/* check result of malloc */
for (i = 0; i < COUNT; i ++) {
ptr = mystruct_zero;
}
And very often, zero-initializing all allocated memory is a waste of
time anyway. Sometimes it's better just to keep track of which
elements haven't been initialized yet.
J
J. J. Farrell
I did, before I posted. Checked dozens of them, starting from
ASCII-1963 through many ASCIIs, GOSTs, JISCII, Thai and Vietnamese
standards, several different EBCIDCs and Soviet EBCDIC rip-offs,
several of the base ECMA standards which later became the core ISO
character set standards, ISO 646, ISO 8859, Unicode. I didn't use the
official Standard documents in many cses, but did in several of them.
Yes, I was bored.
Sometimes value 0 is undefined, other times it represents some other
character. In most cases it has what is variously described as an
acronym, abbreviation, or name of "NUL". In the important modern
standards, "NUL" is the short form, and the English form of the
character name is "NULL". I never saw it called "nul".
So the correct thing to call it in C is the "null character". With the
added restriction that we're thinking in terms of the modern Standard
character sets, it is reasonable to call it both "NUL" and "NULL". The
latter would be a confusing and unfortunate choice in a C context for
obvious reasons.
R
Richard Tobin
J. Sommers said:
How could you tell?
-- Richard
R
Richard Tobin
[/QUOTE]
ISO/IEC 9899 refers normatively to ISO 646-1983 which uses the name
NUL (or nul, case is not significant) for the character with code 0.
Point for especially pedantic pedants: determine whether normative
reference in ISO standards is defined to be equivalent to textual
inclusion.
-- Richard
B
B. Augestad
Richard said:
Wikipedia? According to http://en.wikipedia.org/wiki/Prime_Computer,
Prime Computers died 15 years ago.
Are there still computers made by Prime running somewhere? Hard to tell,
but that's not really important. If Prime is/was the only example of
computers with NULL != all bits zero, we either need more examples or it
is safe to assume that one can use calloc() to zero out pointers.
Bjørn
R
Richard Heathfield
Richard Tobin said:
ISO/IEC 9899 refers normatively to ISO 646-1983 which uses the name
NUL (or nul, case is not significant) for the character with code 0.[/QUOTE]
It can be argued that the reference is not normative, since it occurs in
Section 2, Normative References, which is not explicitly described as
normative by any normative part of the Standard.
Well, that's my fall-back position.
ISO/IEC 9899 refers normatively to ISO 646-1983 which uses the name
NUL (or nul, case is not significant) for the character with code 0.[/QUOTE]
It can be argued that the reference is not normative, since it occurs in
Section 2, Normative References, which is not explicitly described as
normative by any normative part of the Standard.
Well, that's my fall-back position.
K
Keith Thompson
B. Augestad said:
Since the standard makes no such guarantee, a new platform could come
out tomorrow with null pointers having some representation other than
all-bits-zero. Those of us who have avoided making any assumptions
about pointer representation will be able to port our code to the new
platform with no problem (at least not in that area).
C
CBFalconer
B. Augestad said:
Anything running the UCSD (scud) version of a P-code interpreter.
--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews
K
Kenneth Brody
While it may be "safe" to assume that "I am not likely to port my code
to a system in which NULL is not all-bits-zero", you can't say that in
the general sense as far as C is concerned.
BTW, is a C implementation allowed to "make up" whatever it feels like
NULL should be? Could NULL be equivalent to "((void*)&MyNullAddress)"?
(In which case, the actual bit pattern for NULL could change from
program to program, and even from different compiles of the same code.)
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>
to a system in which NULL is not all-bits-zero", you can't say that in
the general sense as far as C is concerned.
BTW, is a C implementation allowed to "make up" whatever it feels like
NULL should be? Could NULL be equivalent to "((void*)&MyNullAddress)"?
(In which case, the actual bit pattern for NULL could change from
program to program, and even from different compiles of the same code.)
--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>
G
Guest
The TenDRA compiler can use either 0x00000000 or 0x55555555 as the
null pointer representation on x86, depending on the compiler options.
(The system libraries need to be built with the same setting as user
programs, of course.)
There's nothing in the C standard that prohibits it. It would be a
pointless complication for both the implementor and the user, but it
would be valid.
null pointer representation on x86, depending on the compiler options.
(The system libraries need to be built with the same setting as user
programs, of course.)
There's nothing in the C standard that prohibits it. It would be a
pointless complication for both the implementor and the user, but it
would be valid.
B
B. Augestad
Harald said:
Are you sure? C99 §6.3.2.3#3 states:
An integer constant expression with the value 0, or such an expression
cast to type void *, is called a null pointer constant.55) If a null
pointer constant is converted to a pointer type, the resulting pointer,
called a null pointer, is guaranteed to compare unequal to a pointer to
any object or function.
§7.17 #3
The macros are NULL which expands to an implementation-defined null
pointer constant;
So NULL must be either 0 or "(void*)0". &MyNullAddress isn't an integer
constant expression, is it?
Bjørn
G
Guest
B. Augestad said:
I read Kenneth Brody's post as saying NULL would compare equal to
&MyNullAddress, not that it would be defined as &MyNullAddress. I also
assumed that he meant &__MyNullAddress or similar.
And as a side note, (1 - 1) or any other integer constant expression
evaluating to 0 is a valid definition of NULL. Also, (void*)0 is not a
valid definition of NULL, because it is not properly parenthesised.
K
Keith Thompson
Kenneth Brody said:
The NULL macro "expands to an implementation-defined null pointer
constant" (C99 7.17p3).
The term "null pointer constant" is defined in C99 6.3.2.3p3:
An integer constant expression with the value 0, or such an
expression cast to type void *, is called a null pointer constant.
"((void*)&MyNullAddress)" doesn't qualify. Furthermore, a "null
pointer" (as distinct from a "null pointer constant") "is guaranteed
to compare unequal to a pointer to any object or function";
"((void*)&MyNullAddress)" fails on that count as well.
Although C99 6.6p10 says:
An implementation may accept other forms of constant expressions.
But of course the conversion of the integer constant 0 to a pointer
type yields an implementation-specific pointer representation, and I
believe that representation can legitimately vary from one execution
of a program to another, as long as it's always treated as a null
pointer within each execution.
Note that the "%p" format used by fprintf() and fscanf() doesn't
restrict the implementation's flexibility here; the converted value is
required to work only during the same program exexution, and there's
no stated exception for null pointers.
G
Gordon Burditt
So NULL must be either 0 or "(void*)0". &MyNullAddress isn't an integer
No, but 0 or (void *)0 in a pointer context may have the same bit pattern
as &MyNullAddress (e.g. 0xdeadbeef).
True, you can't have:
#define NULL (&MyNullAddress)
You possibly could have:
#define NULL (&__MyNullAddress)
where __MyNullAddress has some compiler magic associated with an implicit
definition of it.
No, but 0 or (void *)0 in a pointer context may have the same bit pattern
as &MyNullAddress (e.g. 0xdeadbeef).
True, you can't have:
#define NULL (&MyNullAddress)
You possibly could have:
#define NULL (&__MyNullAddress)
where __MyNullAddress has some compiler magic associated with an implicit
definition of it.