Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: NULL as the empty string
Date: Fri, 08 Dec 2017 16:05:07 -0800
Organization: None to speak of
Lines: 66
Message-ID: <lnr2s4sr4c.fsf@kst-u.example.com>
References: <ov2an8$7sq$1@dont-email.me> <lny3mzte7w.fsf@kst-u.example.com> <0f96b837-7b9a-435f-81ec-8bbc8d2f928b@googlegroups.com> <ln7etxt4ox.fsf@kst-u.example.com> <p0etae$tqd$1@dont-email.me> <lnzi6trkxz.fsf@kst-u.example.com> <p0f1eb$sg1$1@dont-email.me> <lnvahgst7s.fsf@kst-u.example.com> <p0f7ki$6t5$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: reader02.eternal-september.org; posting-host="d19aff521d1f698874161ffa83b5ceb4"; logging-data="17094"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/+6TDWe+0m10UHzMMCRJai"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:leHU0qqIPq6tVN7Z9nvOOhoM2x0= sha1:IhYmq/wB9zc7e7PBYZHuEYbxACk=
Xref: csiph.com comp.lang.c:124032

jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 09/12/2017 à 00:19, Keith Thompson a écrit :
>> Since the cases we're talking about have undefined behavior, a
>> conforming implementation can behave as you propose.  Does lcc-win
>> do this?  If not, are you planning to change it so it does?
>
> Maybe, depends on the pros /cons I see in this discussion. Since any use 
> of NULL in strings is undefined behavior now, I have free hand to do 
> anything. I proposed the following truth table:
>
> strlen(str)
>
> The same behavior. For non NULL pointers nothing changes.
>
> strlen(NULL) --> 0.
>
> For strcat:
>
> strcat(str,str) --> the same
> strcat(str,NULL) -> No-Op. Returns str
> strcat(NULL, str); -> No-Op, returns NULL.
>
> Now, it would be needed to change the definition of a string. A string 
> is either a pointer to an array of zero terminated chars, or NULL, 
> meaning the empty string.

The current definitions (N1570 7.1.1.p1) are:

    A *string* is a contiguous sequence of characters terminated by and
    including the first null character.
    [...]
    A *pointer to a string* is a pointer to its initial (lowest
    addressed) character.

So a string is not a pointer, and a pointer cannot be a string.

Are you proposing to change the definition so that there's no
distinction between a "string" and a "pointer to a string"?  What then
would we call the sequence of characters that's currently defined as a
"string"?  If such a change were to be made to the standard, it would
require changing the wording for every function that acts on strings.

> There are then two representations for the empty string:
>
> NULL or "\0"

You keep referring to NULL (the name of a macro) when you mean the null
pointer.  That's exactly the point that caused the confusion in the
first place.

The way I would describe your proposal is that a null pointer is to be
treated as if it were a pointer to an empty string.  (I'm not sure
whether it would make sense to say that a null pointer actually points
to an empty string.  If so, I'm having difficulty coming up with a
revised definition of "string", since a null pointer does not physically
point to anything.  It might do so on a system where memory address 0
contains a readable 0 bytes, but it would be impractical for the
standard to require that.)

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@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"