pointer doubt (1)

[rashan]

Can ne1 explain me the difference between.... a NULL pointer ... and a
VOID pointer.

With Many Thanks.

[Eric Sosman]

On 5/8/2013 2:46 PM, rashan wrote:
> Can ne1 explain me the difference between.... a NULL pointer ... and a
> VOID pointer.

"NULL" is a macro defined by several of the standard headers.
It expands to a value that can be stored in any pointer variable,
a special value meaning "This pointer has no target" or "This
pointer points nowhere."

"void" (not "VOID") is a type, like "int" or "float". An
"int*" can point at an "int" and a "float*" can point at a "float".
The special magic about a "void*" -- a pointer to "void" -- is
that it can point at any data type. The "void*" is useful when
you need a "pointer to something-or-other" and don't need or want
to worry about what the something-or-other is.

See the comp.lang.c Frequently Asked Questions (FAQ) page
at <http://www.c-faq.com/>; Section 4 covers pointers, Section 5
is specifically about null pointers and NULL, and mentions of
"void*" are sprinkled throughout.

--
Eric Sosman
eso...@comcast-dot-net.invalid

[Joe Pfeiffer]

One is a particular pointer, and the other is a pointer type.

A null pointer is a pointer with a special value that be pointing to
a valid memory object; you can set a pointer to NULL to indicate that
it's invalid and you can test it against NULL to see if it not valid
(note the careful wording; unfortunately, you can have a pointer
containing an essentially random value that isn't pointing to a valid
object as well. So if it's pointing to NULL you know it's invalid; if
it's pointing elsewhere it's only pointing to something valid if the
programmer made it do so).

By a void pointer, I assume you mean something like

void *ptr;

This is a pointer to "memory" of no particular type, which can be cast
to any pointer type you want. It can point to NULL or to somewhere
else.

So if you have

#include <malloc.h>

int *bogus;

bogus = malloc(sizeof int);

then
(1) bogus is a pointer to int
(2) malloc() returns a void*
(3) My call to malloc() requests a pointer to a blob of memory the
right size to hold an int. On a 32 bit system, this is probably
4 bytes.
(4) If the call to malloc() returns NULL, it means it wasn't able to
allocate the requested memory.
(5) The type of the pointer is cast to int* as part of the
assignment.
(6) you can now test

if (bogus == NULL) { ...something... }

to see if malloc() succeeded, and if it did you can say things like

*bogus = 3;

(so the int-size piece of memory pointed to by bogus will now
contain the value 3)

Also see:

http://c-faq.com/ptrs/
http://c-faq.com/~scs/cgi-bin/faqcat.cgi?sec=null

[John Gordon]

NULL is a pointer value.

Void is a pointer type.

When NULL is assigned to a pointer, it typically indicates that the pointer
hasn't been initialized or doesn't point anywhere. On many implementations
the actual value of NULL is zero.

Pointers of type void can be converted to or from any other pointer type.
This is useful when you don't know in advance what type will be needed,
for example the malloc() function.

--
John Gordon A is for Amy, who fell down the stairs
gor...@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"

[Ike Naar]

On 2013-05-08, Joe Pfeiffer <pfei...@cs.nmsu.edu> wrote:
> So if you have
>
> #include <malloc.h>

Nonstandard header.
The standard header for malloc() is <stdlib.h>

> int *bogus;
>
> bogus = malloc(sizeof int);

That won't compile; it should be either

bogus = malloc(sizeof *bogus);

or

bogus = malloc(sizeof (int)); /* note the parentheses */

[Keith Thompson]

Joe Pfeiffer <pfei...@cs.nmsu.edu> writes:
> rashan <nos...@nospam.com> writes:
>
>> Can ne1 explain me the difference between.... a NULL pointer ... and a
>> VOID pointer.
>>
>> With Many Thanks.
>
> One is a particular pointer, and the other is a pointer type.
>
> A null pointer is a pointer with a special value that be pointing to
> a valid memory object; you can set a pointer to NULL to indicate that
> it's invalid and you can test it against NULL to see if it not valid
> (note the careful wording; unfortunately, you can have a pointer
> containing an essentially random value that isn't pointing to a valid
> object as well. So if it's pointing to NULL you know it's invalid; if
> it's pointing elsewhere it's only pointing to something valid if the
> programmer made it do so).

I suggest that the phrase "pointing to NULL", or even "pointing to
null", is misleading.

A null pointer doesn't point to null, it *is* null. More precisely, a
pointer object whose value has been set to NULL contains a null pointer
value; that pointer value doesn't point to *anything*.

A pointer value can be any of the following:

1. A valid pointer to some object;
2. A pointer just past the end of an array;
3. A null pointer, which doesn't point to anything; or
4. An invalid/garbage pointer.

Of these, only (1) can be dereferenced, only (1) and (2) can be
compared with "<", "<=", ">", or ">=", and only (1), (2), and (3)
can be compared with "==" or "!=" or even examined. Violating any
of these rules results in undefined behavior (i.e., don't count on
getting an error message).

Invalid/garbage pointers can be the result of an uninitialized
pointer object, a pointer to an object that no longer exists,
or doing something that has undefined behavior.

[...]

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

John Gordon <gor...@panix.com> writes:
> In <kme6j2$6ue$1...@speranza.aioe.org> rashan <nos...@nospam.com> writes:
>> Can ne1 explain me the difference between.... a NULL pointer ... and a
>> VOID pointer.
>

> NULL is a pointer value.

Close enough. To be pedantic, NULL is a macro that expands to an
implementation-defined null pointer constant; assigning NULL to a
pointer object results in that pointer taking on a null pointer value.
NULL appears in source code; a null pointer value exists during program
execution.

> Void is a pointer type.

"Void" is an arbitrary identifer. "void" is a keyword, and a name for a
predefined incomplete type, not a pointer type. "void*" is a pointer

type.

> When NULL is assigned to a pointer, it typically indicates that the pointer
> hasn't been initialized or doesn't point anywhere. On many implementations
> the actual value of NULL is zero.

The pointer *has* been initialized, but to a value that doesn't point to
anything.

> Pointers of type void can be converted to or from any other pointer type.

Quibble: void* pointers cannot be portably converted to or from function
pointer types.

> This is useful when you don't know in advance what type will be needed,
> for example the malloc() function.

There are actually two distinct rules in play here. One is that an
arbitrary object pointer can be converted to void* and back again
without loss of information. malloc() in particular is guaranteed to
return a pointer that, when converted, is properly aligned to point to
any object type (that's not true of void* pointers in general).

The other is that conversion to and from void* can be done implicitly,
with no cast.

These rules together make things like:

int *ptr = malloc(42 * sizeof *ptr);

possible.

[James Kuyper]

On 05/08/2013 02:46 PM, rashan wrote:
> Can ne1 explain me the difference between.... a NULL pointer ... and a
> VOID pointer.

C is a case sensitive language; the term you're looking for is "null
pointer". NULL is the name of a standard macro. For the same reason,
there's no such thing as a VOID pointer (unless VOID has been given a
meaning by something else, and you'll have to tell us what that meaning
is before we can tell you what "VOID pointer" means). What you're
looking for is "void pointer", or better, "pointer to void".

"void" is a C keyword. It is used in contexts where it could be
interpreted as a type, but it's used exclusively for the purpose of
indicating that no actual type is relevant. In the case of a "pointer to
void", what it means is a pointer to an unspecified type.

A "null pointer constant" is a special phrase in the C language that
does not mean what you might reasonably assume it means by looking at
the individual words that make up the phrase. Not all constant
expressions with a null pointer value qualify; and some of the things
that do qualify are not null pointers at all, but rather integer
expressions. They are, however, constant.

What a "null pointer constant" actually is, is an integer constant
expression (ICE) with a value of 0, or such an expression converted to
the type void* (6.3.2.3p3). Again, ICE is a term that doesn't mean what
you might think by looking at the individual words. It would seem to
mean "an expression with an integer type and a constant value", but in
reality there are a lot of restrictions on what kinds of expressions can
qualify as ICEs. See section 6.6p6 for details on those restrictions.

A null pointer is what you get when a null pointer constant is converted
to a pointer type. Note that "(void*)0" is both a null pointer constant
in it's own right, and a null pointer constant (0) converted to a
pointer type; it is therefore a null pointer. Null pointer constants get
implicitly converted to pointers, and therefore null pointers, whenever
used in certain kinds of operations where a pointer expression could
also be used. For instance, &x==0, where x identifies an object or a
function, causes the null pointer constant 0 to be implicitly converted
to a null pointer of the same type as &x.

The key important facts about null pointers are that all null pointers
compare equal to each other, and that no null pointer compares equal to
a pointer to any object or function. Therefore, &x==0 is guaranteed to
be false. They are normally used as special pointer values - they
indicate that the pointer does NOT, in fact, point at anything.

NULL is a standard macro which is required to expand into a null pointer
constant. In principle, it could be any null pointer constant: '\0', 0s,
0, 0L, 0U, 0UL, 0LL, (3LL-'\03'), (2/3). However, in practice, I don't
know any reason why any implementation would ever define it to be
anything other than 0 or ((void*)0). The second form has an advantage,
in that it can never be misused as an integer.

[Keith Thompson]

rashan <nos...@nospam.com> writes:
> Can ne1 explain me the difference between.... a NULL pointer ... and a
> VOID pointer.

In South Asian English (India, Pakistan), as I understand it,
the word "doubt" is synonymous with "question".

In the rest of the English-speaking world, it isn't. The word
"doubt" implies some level of disbelief. For example, "I have my
doubts about that statement" means, more or less, "I think that
statement is probably false".

We get a lot of questions here from people who use "doubt" as a
synonym for "question", so we've (gradually) learned to accept
it, but you might consider using the word "question" instead when
writing for a wide audience.

[glen herrmannsfeldt]

Keith Thompson <ks...@mib.org> wrote:

(snip)

> I suggest that the phrase "pointing to NULL", or even "pointing to
> null", is misleading.

> A null pointer doesn't point to null, it *is* null. More precisely, a
> pointer object whose value has been set to NULL contains a null pointer
> value; that pointer value doesn't point to *anything*.

Hmm. If "null" is a synonm for "nothing,", and an antonym for
"anything" then "point to null" seems to mean the same thing as
"point to nothing" or "not point to anything."

I suppose one could say "has a value that compares equal to the
NULL pointer constant", but "points to null" is a lot easier to
say and write.

-- glen

[Joe Pfeiffer]

Thank you. That's what I get for not compiling my examples.

[James Kuyper]

On 05/08/2013 08:33 PM, glen herrmannsfeldt wrote:
> Keith Thompson <ks...@mib.org> wrote:
>
> (snip)
>
>> I suggest that the phrase "pointing to NULL", or even "pointing to
>> null", is misleading.
>
>> A null pointer doesn't point to null, it *is* null. More precisely, a
>> pointer object whose value has been set to NULL contains a null pointer
>> value; that pointer value doesn't point to *anything*.
>
> Hmm. If "null" is a synonm for "nothing,", and an antonym for
> "anything" then "point to null" seems to mean the same thing as
> "point to nothing" or "not point to anything."

Historically, the use of "null" to describe pointers was not intended to
describe what the pointer points at, but rather how it's represented. On
many systems, particularly at that time, and particularly the ones C was
first developed on, there was no practical difference between pointers
an integers of the same size, and a null pointer was a pointer that had
the same representation as an integer 0. This is not mandated by the C
standard, and there's many systems where it's not true, but that it the
origin of the terminology.

> I suppose one could say "has a value that compares equal to the
> NULL pointer constant", but "points to null" is a lot easier to
> say and write.

"null pointer" is even easier, and has the advantage of being a
standard-defined term.
--
James Kuyper

[James Kuyper]

On 05/08/2013 08:33 PM, glen herrmannsfeldt wrote:

> Keith Thompson <ks...@mib.org> wrote:
>
> (snip)
>
>> I suggest that the phrase "pointing to NULL", or even "pointing to
>> null", is misleading.
>
>> A null pointer doesn't point to null, it *is* null. More precisely, a
>> pointer object whose value has been set to NULL contains a null pointer
>> value; that pointer value doesn't point to *anything*.
>
> Hmm. If "null" is a synonm for "nothing,", and an antonym for
> "anything" then "point to null" seems to mean the same thing as
> "point to nothing" or "not point to anything."

Historically, the use of "null" to describe pointers was not intended to
describe what the pointer points at, but rather how it's represented. On
many systems, particularly at that time, and particularly the ones C was
first developed on, there was no practical difference between pointers
an integers of the same size, and a null pointer was a pointer that had
the same representation as an integer 0. This is not mandated by the C
standard, and there's many systems where it's not true, but that it the
origin of the terminology.

> I suppose one could say "has a value that compares equal to the
> NULL pointer constant", but "points to null" is a lot easier to
> say and write.

[pete]

On 5/8/2013 3:16 PM, Joe Pfeiffer wrote:

> A null pointer is a pointer with a special value that be pointing to
> a valid memory object;

ITYM "doesn't point" instead of "be pointing".

--
pete

[Ken Brody]

On 5/8/2013 2:46 PM, rashan wrote:

> Can ne1 explain me the difference between.... a NULL pointer ... and a
> VOID pointer.

Well, I'm not sure who this "ne1" person is, but I'll take a shot...


"What is the difference between an empty box and a cardboard box?"


Now, assuming you meant a "null pointer" and a "void pointer" (using ALL
CAPS for emphasis)...

A "null pointer" is a pointer, of any type, which points to nothing. (It
"points" to a special location, which can be referred to as NULL, which has
a special meaning of "nowhere".)

A "void pointer" is a specific *type* of pointer -- one which can point to
*any* type of value.

Note that a pointer can be both a "void pointer" and a "null pointer":

void *foo = NULL;


In short, a "null pointer" is a pointer which contains a specific *value*,
whereas a "void pointer" is a pointer of a particular *type*.

[Johannes Bauer]

On 08.05.2013 22:10, Keith Thompson wrote:

>> NULL is a pointer value.
>
> Close enough. To be pedantic, NULL is a macro that expands to an
> implementation-defined null pointer constant;

[...]

>> When NULL is assigned to a pointer, it typically indicates that the pointer
>> hasn't been initialized or doesn't point anywhere. On many implementations
>> the actual value of NULL is zero.
>
> The pointer *has* been initialized, but to a value that doesn't point to
> anything.

I don't understand why you nitpick the difference between compile- and
runtime, but then say that "NULL" doesn't point to anything. To be
pedantic, NULL points to an implementation-defined location (as you
yourself wrote). What the results of dereferencing that location are is
implementation-defined. How is that "nothing"?

Regards,
Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1...@speranza.aioe.org>

[Vincenzo Mercuri]

Il 13/05/2013 12:09, Johannes Bauer ha scritto:
[..]

> I don't understand why you nitpick the difference between compile- and
> runtime, but then say that "NULL" doesn't point to anything. To be
> pedantic, NULL points to an implementation-defined location (as you
> yourself wrote). What the results of dereferencing that location are is

> implementation-defined. [..]

No, it's undefined behavior:

N1256, 6.5.3.2p4:

"(..) If an invalid value has been assigned to the pointer,
the behavior of the unary * operator is undefined."

footnote 87:

"(..) Among the invalid values for dereferencing a pointer by the
unary * operator are a null pointer, an address inappropriately
aligned for the type of object pointed to, and the address of
an object after the end of its lifetime."


--
Vincenzo Mercuri

[glen herrmannsfeldt]

Johannes Bauer <dfnson...@gmx.de> wrote:

(snip)

>> The pointer *has* been initialized, but to a value that doesn't point to
>> anything.

> I don't understand why you nitpick the difference between compile- and
> runtime, but then say that "NULL" doesn't point to anything. To be
> pedantic, NULL points to an implementation-defined location (as you
> yourself wrote). What the results of dereferencing that location are is
> implementation-defined. How is that "nothing"?

For some systems, a specific address, usually zero, is reserved by the
software, but is otherwise a valid address. Some libraries test at the
end that the same value is still stored there, and give a message if the
value has changed. The null pointer does point somewhere, but you aren't
supposed to do anything there.

For protected mode x86 (starting with the 80286), segment selector zero
is reserved by the hardware as the null segment selector. There is no
segment descriptor for selector zero. That is the way the hardware
works.

-- glen

[James Kuyper]

On 05/13/2013 06:09 AM, Johannes Bauer wrote:
> On 08.05.2013 22:10, Keith Thompson wrote:
>
>>> NULL is a pointer value.
>>
>> Close enough. To be pedantic, NULL is a macro that expands to an
>> implementation-defined null pointer constant;
>
> [...]
>
>>> When NULL is assigned to a pointer, it typically indicates that the pointer
>>> hasn't been initialized or doesn't point anywhere. On many implementations
>>> the actual value of NULL is zero.
>>
>> The pointer *has* been initialized, but to a value that doesn't point to
>> anything.
>
> I don't understand why you nitpick the difference between compile- and
> runtime, but then say that "NULL" doesn't point to anything. To be
> pedantic, NULL points to an implementation-defined location (as you

> yourself wrote). ...

The NULL macro expands to an implementation-defined null pointer
constant (7.19p3). That means it's implementation-defined whether that
constant is 0, '\0', 0ULL, (3-3), (void*)(2/3), or any other null
pointer constant. That doesn't mean the location it points at is
implementation-defined.

When a null pointer constant is converted to a pointer type, the result
is a null pointer. How that pointer is represented is up to each
implementor to decide, but it is not implementation-defined. That means
that the implementation has no obligation to document it. Even if it
were implementation-defined, it would not necessarily be a pointer
pointing at an implementation-defined location. It could also be a
pointer that is invalid, as far as the hardware is concerned, pointing
nowhere.

A null pointer is prohibited from comparing equal to a pointer to any
object or function (6.3.2.3p3). In practice, a null pointer is often
(but not always) represented by something that would, if dereferenced,
behave as an ordinary pointer retrieving it's value from whatever is
currently stored in a specific location in memory - but that's not
required by the standard.

> ... What the results of dereferencing that location are is

> implementation-defined. How is that "nothing"?

Those results are not implementation-defined, they are undefined. That's
not "nothing", it's everything. A program that dereferences a null
pointer has behavior that is not constrained in any way by the C
standard. That means, in particular, that the behavior need not take a
form that could be interpreted as indicating that the null pointer was
merely an ordinary pointer pointing at a unspecified location in memory
(though that, in itself, would be sufficient to cause fatally sever
problems, depending upon the type being pointed at, and the contents of
the unspecified memory location).
--
James Kuyper

[James Kuyper]

On 05/13/2013 06:09 AM, Johannes Bauer wrote:

> On 08.05.2013 22:10, Keith Thompson wrote:
>
>>> NULL is a pointer value.
>>
>> Close enough. To be pedantic, NULL is a macro that expands to an
>> implementation-defined null pointer constant;
>
> [...]
>
>>> When NULL is assigned to a pointer, it typically indicates that the pointer
>>> hasn't been initialized or doesn't point anywhere. On many implementations
>>> the actual value of NULL is zero.
>>
>> The pointer *has* been initialized, but to a value that doesn't point to
>> anything.
>
> I don't understand why you nitpick the difference between compile- and
> runtime, but then say that "NULL" doesn't point to anything. To be
> pedantic, NULL points to an implementation-defined location (as you

> yourself wrote). ...

The NULL macro expands to an implementation-defined null pointer
constant (7.19p3). That means it's implementation-defined whether that
constant is 0, '\0', 0ULL, (3-3), (void*)(2/3), or any other null
pointer constant. That doesn't mean the location it points at is
implementation-defined.

When a null pointer constant is converted to a pointer type, the result
is a null pointer. How that pointer is represented is up to each
implementor to decide, but it is not implementation-defined. That means
that the implementation has no obligation to document it. Even if it
were implementation-defined, it would not necessarily be a pointer
pointing at an implementation-defined location. It could also be a
pointer that is invalid, as far as the hardware is concerned, pointing
nowhere.

A null pointer is prohibited from comparing equal to a pointer to any
object or function (6.3.2.3p3). In practice, a null pointer is often
(but not always) represented by something that would, if dereferenced,
behave as an ordinary pointer retrieving it's value from whatever is
currently stored in a specific location in memory - but that's not
required by the standard.

> ... What the results of dereferencing that location are is

> implementation-defined. How is that "nothing"?

[Eric Sosman]

On 5/13/2013 6:09 AM, Johannes Bauer wrote:
> On 08.05.2013 22:10, Keith Thompson wrote:
>
>>> NULL is a pointer value.
>>
>> Close enough. To be pedantic, NULL is a macro that expands to an
>> implementation-defined null pointer constant;
>
> [...]
>
>>> When NULL is assigned to a pointer, it typically indicates that the pointer
>>> hasn't been initialized or doesn't point anywhere. On many implementations
>>> the actual value of NULL is zero.
>>
>> The pointer *has* been initialized, but to a value that doesn't point to
>> anything.
>
> I don't understand why you nitpick the difference between compile- and
> runtime, but then say that "NULL" doesn't point to anything. To be
> pedantic, NULL points to an implementation-defined location (as you
> yourself wrote). What the results of dereferencing that location are is
> implementation-defined. How is that "nothing"?

To be pedantic, NULL is a macro. During compilation, it
expands to a /null pointer constant/. Oddly enough, the value
of an NPC is not necessarily a pointer at all! It can, however,
be converted to a pointer type, and the conversion produces a
/null pointer/. Unless I've missed something, there are only
three guarantees about a null pointer:

- It "is guaranteed to compare unequal to a pointer to any
object or function" (6.3.2.3p3).

- Converting a type A* null pointer to type B* produces a
null pointer of type B* (6.3.2.3p4).

- "Any two null pointers shall compare equal" (6.3.2.3p4 again).

Nowhere is it required or even suggested that a null pointer
(or NULL) points anywhere or to anything, nor is the effect of a
dereference implementation-defined (it is /undefined behavior/,
which an implementation is permitted but not obligated to define;
/implementation-defined behavior/, on the other hand, requires a
definition).

As far as I can see, the only implementation-defined feature
of NULL is the precise form of null pointer constant to which it
expands. The Standard describes some forms like `0' and `(void*)0'
and `(5/9)' that qualify as null pointer constants, but the NULL
macro might expand to, say, `__builtin_nil'. Such a spelling might
enable a compiler to produce better diagnostics for suspicious
constructs like `char ptr = NULL;' than if NULL expanded to plain
`0', but does not affect the meaning of the code (if any).

--
Eric Sosman
eso...@comcast-dot-net.invalid

[Keith Thompson]

Johannes Bauer <dfnson...@gmx.de> writes:
> On 08.05.2013 22:10, Keith Thompson wrote:
>>> NULL is a pointer value.
>>
>> Close enough. To be pedantic, NULL is a macro that expands to an
>> implementation-defined null pointer constant;
>
> [...]
>
>>> When NULL is assigned to a pointer, it typically indicates that the pointer
>>> hasn't been initialized or doesn't point anywhere. On many implementations
>>> the actual value of NULL is zero.
>>
>> The pointer *has* been initialized, but to a value that doesn't point to
>> anything.
>
> I don't understand why you nitpick the difference between compile- and
> runtime, but then say that "NULL" doesn't point to anything. To be
> pedantic, NULL points to an implementation-defined location (as you
> yourself wrote). What the results of dereferencing that location are is
> implementation-defined. How is that "nothing"?

As long as we're being pedantic, NULL is an identifier, defined
as a macro if any of certain standard headers are included, that
expands to a null pointer constant. Both NULL and null pointer
constants exist only in C source code. A null pointer *value*
can exist during execution. I didn't say that NULL doesn't point
to anything, I said that a null pointer doesn't point to anything.

You say that I wrote that a null pointer points to an
implementation-defined location. It does not, and I never said
it does. The only implementation-defined thing that I mentioned
in my previous post is the null pointer constant to which the NULL
macro expands. For example, NULL might expand either to 0 or to
((void*)0), both of which are null pointer constants, and both of
which denote the same run-time pointer value, namely a null pointer.

Again, a null pointer, at least in the abstract machine, does not
point to anything. If it pointed to "an implementation-defined
location", that would mean that each implementation would
have to document what that location is; there is no such
requirement. The result of dereferencing a null pointer are not
implementation-defined; they are undefined.

On *some* implementations, a null pointer may happen to be the
address of some memory location, but the standard says nothing
about what that location might be, or whether it even exists.