Re: NULL as the empty string

From	Keith Thompson <kst-u@mib.org>
Newsgroups	comp.lang.c
Subject	Re: NULL as the empty string
Date	2017-11-21 15:16 -0800
Organization	None to speak of
Message-ID	<lny3mzte7w.fsf@kst-u.example.com> (permalink)
References	<ov2an8$7sq$1@dont-email.me>

Show all headers | View raw

jacobnavia <jacob@jacob.remcomp.fr> writes:
> Whaat would happen if we decide to give meaning to NULL?

NULL (more precisely a null pointer) has a meaning.  It's a pointer
value that doesn't point to anything.

> Assume that in all places of the string library (strlen, strcmp, etc) a 
> NULL was the equivalent of the string "\0"
>
> strlen would return zero, etc. This way, we would save terabytes of "\0" 
> strings since an empty string would not require any storage, since it is 
> empty of course!

We already have a way to represent an empty string.  I don't think we
need another.  Currently, a pointer to an empty string and a pointer
that doesn't point to a string are two different things, and programs
can make good use of that distinction.  And since so much existing
code has most likely already been tested on systems that trap on
operations on null pointers, most code that assumed a null pointer
is a valid way to represent an empty string has *already* been fixed.

> fopen("myfile.txt",NULL) would mean that a default value would be chosen 
> for file permissions, and fopen(NULL,NULL) would send all data to the 
> bitbucket (a NOP) since it would return NULL. A NULL file would discard 
> all output and in input it would always return EOF.

There's currently no portable way to refer to the "bit bucket" file
("/dev/null", "NUL", etc.).  Treating either the empty string or a null
pointer as an alias for the system's bit bucket file might be useful.
(But we've gotten along without such a mechanism so far.)  On the other
hand, I think a macro whose value is the name of the bit bucket file
would be cleaner.  If the underlying system doesn't support such a file
or device, the implementation could indicate that by not defining the
macro.

As for the mode string argument ("r", "rw", etc.), I don't see the
benefit of a default value.  If you want to open a file for reading,
use "r".  Are you suggesting that the default value might be different
for different systems?  If so, I don't see any benefit in that.

> NULL could mean "empty string" or "Use the default value" or many other 
> useful information, using zero storage...
>
> What do you think?

Programs can already assign any meaning they like to null pointers.
I don't see much benefit in changing the standard library's behavior.
There's something to be said, I suppose, for treating null pointer
arguments as errors that must be detected, but that only solves a
small part of the problem; there's no good way to detect invalid
non-null pointers.

-- 
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

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 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 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

csiph-web