Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #124170
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: NULL as the empty string |
| Date | 2017-12-11 11:19 -0800 |
| Organization | None to speak of |
| Message-ID | <lnvahdoyw7.fsf@kst-u.example.com> (permalink) |
| References | (1 earlier) <f92tlaFp91dU8@mid.individual.net> <lny3mbr6rv.fsf@kst-u.example.com> <p0kk96$h7s$1@dont-email.me> <lnbmj6q7an.fsf@kst-u.example.com> <p0mgs5$bbv$1@dont-email.me> |
jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 11/12/2017 à 04:20, Keith Thompson a écrit :
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>> Le 09/12/2017 à 21:22, Keith Thompson a écrit :
>>>> But if the standard were changed to treat a null pointer as if it
>>>> were a pointer to an empty string, then non-standard functions
>>>> would likely return a null pointer to denote an empty string.
>>>> For example, strdup() (which is POSIX, not ISO C) might return
>>>> a null pointer given a null pointer argument -- or even given a
>>>> non-null pointer to an empty string.
>>>
>>> Truth table:
>>>
>>> strdup(str) --> NULL or a malloced string.
>>> strdup(NULL) --> NULL.
>>>
>>> Everything would stay the same.
>>
>> (That's not a "truth table". The entries in a truth table are true or
>> false.)
>
> For binary logic yes. For use as an exhaustive description of several
> alternatives no.
This is a minor point, but I stand by my statement that what you
presented above is not a "truth table". If you want to keep calling it
that I can't stop you.
>> Would strdup(NULL) returning a malloced empty string be non-conforming?
>
> Yes. No storage has been given to duplicate, so strdup shoudn't allocate
> any space
You've said that a null pointer (which you continue to insist on calling
"NULL", which is the name of a macro) is a pointer to an empty string.
If strdup(NULL) returning a non-null pointer to a malloced empty string
is going to be non-conforming, there would have to be specific wording
to that effect. Note that this would affect the POSIX standard; the
side effects of your proposed change are not limited to ISO C.
>>> Unless you WANT to crash within strdup and not when the NULL pointer
>>> result is dereferenced. In that case (as in the others)
>>>
>>> #define strdup TrappingStrdup
>>>
>>> char *TrappingStrdup(char *str)
>>> {
>>> if (*str == 0)
>>> ;
>>> return strdup(str);
>>> }
>>
>> Or I can just use strdup() as it's currently implemented (though *str
>> has undefined behavior and is not guaranteed to trap). For that matter,
>> since evaluting *str has undefined behavior, a compiler could assume
>> that str is non-null thereafter.
>
> That's a correct assumption. If "str" is NULL it will trap right there.
Who says it will trap? As we've discussed here recently (in fact I
think it's what triggered this discussion), there have been systems on
which a null pointer points to memory address 0, and that address
contained a readable zero byte. If str==NULL, then (*str == 0) on such
a system could yield 1 (true). This is, as you know, the nature of
undefined behavior.
>> But that raises an interesting question. In C as it's currently
>> defined, if s is a pointer to an empty string:
>>
>> const char *s = "";
>>
>> then *s and s[0] both yield '\0', and more generally, if s is a pointer
>> to a string then s[strlen(s)] == '\0'. With your proposed change, that
>> guarantee would be broken. s could be (treated as) a pointer to an
>> empty string, but if s==NULL then *s and s[0] would have undefined
>> behavior (and would likely trap).
>
> Yes. Note that NULL would be a *representation* of the empty string, not
> an empty string.
A null pointer would be a treated as a pointer to an empty string. Of
course a pointer isn't a string.
> This is a bogus issue since none of the str* functions
> would return NULL when given actual strings. The whole behavior of the
> string functions would NOT change. They would have a defined behavior
> for NULL arguments, that's all.
I don't believe there are any standard library functions that return a
pointer to a string that didn't already exist before the function was
called. strdup() was excluded from the C standard because it does that.
The defined behavior of the standard string functions would not change.
I'm talking about string functions not defined by the standard.
>> If I want to traverse a string, I can write:
>>
>> for (ptr = s; *ptr != '\0' ptr ++) {
>> do_something_with(*ptr);
>> }
>>
>> and it will work if ptr points to a string. Under your proposal,
>> ptr==NULL would make it a valid pointer to a string, but the above
>> code would break.
>
> Yes, you can't "traverse" the representation of an empty string. Note
> that if "s" is NULL your code will crash now anyway.
An empty string, in C as it's currently defined, is a sequence
consisting of a single null character, and I certainly can traverse it.
You're not just proposing a change to the implementation of the C
standard library. You're proposing a change in the definition of
"pointer to a string" that will require updating existing code.
Say I provide this function in a library:
size_t sum_str(const char *s) {
size_t sum = 0;
while (*s != '\0') {
sum += (unsigned char)*s;
s ++;
}
return sum;
}
Currently, sum_str(NULL) has undefined behavior. Let's assume
your proposal is adopted in a future C standard. Programmers will
reasonably assume that a null pointer is a valid pointer to an
empty string -- but sum_str(NULL) will still have undefined behavior.
If all such functions aren't updated (and they won't be), then we'll
have two different models, one in which a null pointer is not a valid
pointer to a string, and one in which it's a valid pointer to an empty
string. Mixing code using those two different models will inevitably
lead to bugs that wouldn't have occurred otherwise.
[...]
If you want to update lcc-win's library implementation so it checks for
null pointers and treats them as pointers to empty strings, I have no
particular objection. I do oppose making such a change to the C
standard.
--
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"
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
NULL as the empty string jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-21 23:52 +0100
Re: NULL as the empty string Keith Thompson <kst-u@mib.org> - 2017-11-21 15:16 -0800
Re: NULL as the empty string jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-22 00:38 +0100
Re: NULL as the empty string Keith Thompson <kst-u@mib.org> - 2017-11-21 16:02 -0800
Re: NULL as the empty string jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-22 01:13 +0100
Re: NULL as the empty string Keith Thompson <kst-u@mib.org> - 2017-11-21 16:52 -0800
Re: NULL as the empty string Robert Wessel <robertwessel2@yahoo.com> - 2017-11-21 18:09 -0600
Re: NULL as the empty string Siri Cruise <chine.bleu@yahoo.com> - 2017-11-21 16:34 -0800
Re: NULL as the empty string David Brown <david.brown@hesbynett.no> - 2017-11-22 12:12 +0100
Re: NULL as the empty string supercat@casperkitty.com - 2017-11-21 15:57 -0800
Re: NULL as the empty string jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-22 01:06 +0100
Re: NULL as the empty string supercat@casperkitty.com - 2017-11-22 15:42 -0800
Re: NULL as the empty string Melzzzzz <Melzzzzz@zzzzz.com> - 2017-11-22 23:49 +0000
Re: NULL as the empty string supercat@casperkitty.com - 2017-11-22 15:56 -0800
Re: NULL as the empty string Melzzzzz <Melzzzzz@zzzzz.com> - 2017-11-23 00:06 +0000
Re: NULL as the empty string supercat@casperkitty.com - 2017-11-23 17:31 -0800
Re: NULL as the empty string jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-24 09:42 +0100
Re: NULL as the empty string supercat@casperkitty.com - 2017-11-24 13:47 -0800
Re: NULL as the empty string Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-11-22 06:46 +0000
Re: NULL as the empty string John Bode <jfbode1029@gmail.com> - 2017-12-08 10:27 -0800
Re: NULL as the empty string Keith Thompson <kst-u@mib.org> - 2017-12-08 11:11 -0800
Re: NULL as the empty string jacobnavia <jacob@jacob.remcomp.fr> - 2017-12-08 21:39 +0100
Re: NULL as the empty string Keith Thompson <kst-u@mib.org> - 2017-12-08 13:03 -0800
Re: NULL as the empty string jacobnavia <jacob@jacob.remcomp.fr> - 2017-12-08 22:50 +0100
Re: NULL as the empty string Keith Thompson <kst-u@mib.org> - 2017-12-08 15:19 -0800
Re: NULL as the empty string jacobnavia <jacob@jacob.remcomp.fr> - 2017-12-09 00:35 +0100
Re: NULL as the empty string Keith Thompson <kst-u@mib.org> - 2017-12-08 16:05 -0800
Re: NULL as the empty string jacobnavia <jacob@jacob.remcomp.fr> - 2017-12-09 01:22 +0100
Re: NULL as the empty string Keith Thompson <kst-u@mib.org> - 2017-12-08 17:39 -0800
Re: NULL as the empty string John Bode <jfbode1029@gmail.com> - 2017-12-11 12:22 -0800
Re: NULL as the empty string jacobnavia <jacob@jacob.remcomp.fr> - 2017-12-09 01:29 +0100
Re: NULL as the empty string Keith Thompson <kst-u@mib.org> - 2017-12-08 17:47 -0800
Re: NULL as the empty string jacobnavia <jacob@jacob.remcomp.fr> - 2017-12-09 07:05 +0100
Re: NULL as the empty string David Brown <david.brown@hesbynett.no> - 2017-12-09 18:37 +0100
Re: NULL as the empty string Keith Thompson <kst-u@mib.org> - 2017-12-09 11:53 -0800
Re: NULL as the empty string supercat@casperkitty.com - 2017-12-12 10:49 -0800
Re: NULL as the empty string Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-12-12 13:39 -0800
Re: NULL as the empty string supercat@casperkitty.com - 2017-12-12 16:05 -0800
Re: NULL as the empty string Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-12-13 03:43 -0800
Re: NULL as the empty string supercat@casperkitty.com - 2017-12-13 08:45 -0800
Re: NULL as the empty string Keith Thompson <kst-u@mib.org> - 2017-12-13 09:12 -0800
Re: NULL as the empty string Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-12-13 13:27 -0800
Re: NULL as the empty string Keith Thompson <kst-u@mib.org> - 2017-12-13 14:02 -0800
Re: NULL as the empty string asetofsymbols@gmail.com - 2017-12-13 14:58 -0800
Re: NULL as the empty string asetofsymbols@gmail.com - 2017-12-13 15:11 -0800
Re: NULL as the empty string Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-12-14 03:49 -0800
Re: NULL as the empty string mark.bluemel@gmail.com - 2017-12-14 04:05 -0800
Re: NULL as the empty string David Brown <david.brown@hesbynett.no> - 2017-12-14 13:09 +0100
Re: NULL as the empty string Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-12-14 05:02 -0800
Re: NULL as the empty string David Brown <david.brown@hesbynett.no> - 2017-12-14 14:54 +0100
Re: NULL as the empty string supercat@casperkitty.com - 2017-12-14 07:38 -0800
Re: NULL as the empty string Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-12-14 09:50 -0800
Re: NULL as the empty string Keith Thompson <kst-u@mib.org> - 2017-12-14 09:20 -0800
Re: NULL as the empty string supercat@casperkitty.com - 2017-12-14 09:53 -0800
Re: NULL as the empty string Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-12-14 12:57 -0800
Re: NULL as the empty string herrmannsfeldt@gmail.com - 2017-12-14 17:22 -0800
Re: NULL as the empty string Keith Thompson <kst-u@mib.org> - 2017-12-14 17:26 -0800
Re: NULL as the empty string jacobnavia <jacob@jacob.remcomp.fr> - 2017-12-08 21:23 +0100
Re: NULL as the empty string Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-12-08 13:41 -0800
Re: NULL as the empty string jacobnavia <jacob@jacob.remcomp.fr> - 2017-12-08 22:54 +0100
Re: NULL as the empty string supercat@casperkitty.com - 2017-11-21 15:17 -0800
Re: NULL as the empty string jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-22 00:26 +0100
Re: NULL as the empty string supercat@casperkitty.com - 2017-11-21 16:03 -0800
Re: NULL as the empty string "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-11-22 00:27 +0100
Re: NULL as the empty string jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-22 00:42 +0100
Re: NULL as the empty string Keith Thompson <kst-u@mib.org> - 2017-11-21 16:05 -0800
Re: NULL as the empty string herrmannsfeldt@gmail.com - 2017-12-06 22:33 -0800
Re: NULL as the empty string supercat@casperkitty.com - 2017-12-07 12:04 -0800
Re: NULL as the empty string jacobnavia <jacob@jacob.remcomp.fr> - 2017-12-07 23:20 +0100
Re: NULL as the empty string supercat@casperkitty.com - 2017-12-07 15:04 -0800
Re: NULL as the empty string Keith Thompson <kst-u@mib.org> - 2017-11-21 15:28 -0800
Re: NULL as the empty string Thiago Adams <thiago.adams@gmail.com> - 2017-11-21 16:04 -0800
Re: NULL as the empty string Siri Cruise <chine.bleu@yahoo.com> - 2017-11-21 16:25 -0800
Re: NULL as the empty string jacobnavia <jacob@jacob.remcomp.fr> - 2017-11-22 01:34 +0100
Re: NULL as the empty string bartc <bc@freeuk.com> - 2017-11-22 00:36 +0000
Re: NULL as the empty string Öö Tiib <ootiib@hot.ee> - 2017-11-21 23:07 -0800
NULL as the empty string asetofsymbols@gmail.com - 2017-11-23 22:23 -0800
Re: NULL as the empty string Geoff <geoff@invalid.invalid> - 2017-12-09 09:05 -0800
Re: NULL as the empty string Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2017-12-09 12:40 -0500
Re: NULL as the empty string gordonb.yj0bc@burditt.org (Gordon Burditt) - 2017-12-09 13:50 -0600
Re: NULL as the empty string Ian Collins <ian-news@hotmail.com> - 2017-12-10 08:59 +1300
Re: NULL as the empty string Keith Thompson <kst-u@mib.org> - 2017-12-09 12:22 -0800
Re: NULL as the empty string jacobnavia <jacob@jacob.remcomp.fr> - 2017-12-11 01:42 +0100
Re: NULL as the empty string Keith Thompson <kst-u@mib.org> - 2017-12-10 19:20 -0800
Re: NULL as the empty string jacobnavia <jacob@jacob.remcomp.fr> - 2017-12-11 18:56 +0100
Re: NULL as the empty string Keith Thompson <kst-u@mib.org> - 2017-12-11 11:19 -0800
Re: NULL as the empty string supercat@casperkitty.com - 2017-12-15 09:29 -0800
Re: NULL as the empty string Thiago Adams <thiago.adams@gmail.com> - 2018-01-05 08:28 -0800
Re: NULL as the empty string supercat@casperkitty.com - 2018-01-05 09:37 -0800
Re: NULL as the empty string Thiago Adams <thiago.adams@gmail.com> - 2018-01-05 17:08 -0800
Re: NULL as the empty string supercat@casperkitty.com - 2017-12-15 09:18 -0800
csiph-web