Re: interpreting a null pointer as an empty (null string)

From: Leor Zolman (leor_at_bdsoft.com)
Date: 03/09/04 

Date: Tue, 09 Mar 2004 14:30:44 GMT

On Tue, 09 Mar 2004 13:30:41 GMT, rlb@hoekstra-uitgeverij.nl (Richard Bos)
wrote:

>Leor Zolman <leor@bdsoft.com> wrote:
>
>> "Among the invalid values for dereferencing a pointer by the unary *
>> operator are a null pointer,..."
>>
>> Sorry for beating a seemingly dead horse, but I'm not seeing how this
>> leaves any wiggle room to make that operation "valid".
>
>You are correct, but I think there's been a miscommunication along this
>thread. To me, and it seems to Keith as well, it looked as if you were
>saying that treating null pointer dereferences as empty string
>references is illegal, for the implementation. This is not true.

No, I was actually saying (and I'm still working on letting myself be
talked out of it) that the discussion shouldn't even /reach/ the point of
asking how the result of such a dereference may be treated, because getting
there requires doing something that has undefined behavior (or, at least,
involves the use of something that has been labeled as "invalid").
 
Okay, this is good. Perhaps I'm about to get how I went astray. Setting the
Way-back machine to my message dated 3/8 at 8:05pm, here's how I re-entered
the fray:

------------------------------------------------------------------------
>> Those on systems that map memory page zero as an unused, all zeros
>> memory page, typically read only. Thus, you have a null character at
>> memory address 0, which is the usual destination of the null pointer.
>
>Absolutely unportable, implementation-dependent, and
>maybe operating system level dependent.

Looks like this is explicitly disallowed by the Standard, to boot. Section
6.5.3.2, footnote 83, says (in part):
        "Among the invalid values for dereferencing a pointer by the unary *
        operator are a null pointer, ..."
------------------------------------------------------------------------

I used the words "explicitly disallowed" when citing the footnote about
null pointers being "invalid" as operands of the indirection operator; my
thinking here was that any implementation that actually tries to /look/ at
location zero through a null pointer would therefore be in direct
violation of the standard (and not "just" doing something whose outcome is
implementation-dependent.) Yet everyone here is telling me that platforms
are free to allow such dereferencing...

>
>_You_ are not allowed to dereference a null pointer. Doing so is
>undefined behaviour. This means that, once you _have_ done so, the
>implementation is free to treat it any way it pleases - which includes
>pretending that you'd dereferenced a pointer to an empty string. IOW,
>you're not supposed to rely on this, but the implementation doesn't
>break the Standard if it lets you do so.

So is there actually any difference whatsoever in anybody's mind between
something labeled by the Standard as "undefined behavior" and something
else labeled an "invalid" practice? Let me postulate that the answer is
"no".

And then: Would I be correct in saying that the difference between code
that is "disallowed" and code that is invalid/has undefined behavior is
that being "disallowed" requires the compiler to diagnose it, while
invalid/UB code does /not/ require the compiler to diagnose it, and such
code may have well-defined behavior in the domain of some arbitrary
platform (thus of course being non-portable)?

I feel close, really close... ;-)
Thanks all,
        -leor

Leor Zolman
BD Software
leor@bdsoft.com
www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
           Decryptor at www.bdsoft.com/tools/stlfilt.html

Relevant Pages

  • Re: Adjacent arrays in C99
    ... Same result as the first example -- undefined behavior. ... terms of a pointer pointing into, or one past, 'an array object'. ... Standard says that no restrictions apply on what implementations ...
    (comp.std.c)
  • Re: use delete to destroy primitive/object types but memory is not freed
    ... >> invokes undefined behavior, even if you don't dereference it. ... Recall that g is a pointer to double. ... the operating system or some other standard. ... > But you said, "Also, any reference to g, the pointer variable, ...
    (comp.lang.c)
  • Re: Highly efficient string reversal code
    ... uninitialised pointer. ... NOTE Possible undefined behavior ranges from ignoring the ... very beginning of a segment. ... standard is specifically designed to allow such an implementation. ...
    (comp.lang.c)
  • Re: HELP! - time function problem??
    ... the reception of a null pointer leads to ... >>> undefined behavior because the parameters to the sprintf statement ... >>> Standard function ctime may invoke undefined behavior. ... But what exactly constitutes "cannot be converted to local time"? ...
    (comp.lang.c)
  • Re: Reading from invalid memory
    ... from the same invalid memory location I do not get any errors. ... since constructing or dereferencing an invalid pointer ... Undefined behavior can be anything, ...
    (comp.unix.programmer)