Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #123245

Re: NULL as the empty string

Show key headers only | View raw

jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 22/11/2017 à 00:16, Keith Thompson a écrit :
>> 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.  
>
> So, to store the empty string you need a pointer (8 bytes in 64 bit 
> machines), and a zero byte? Tha makes 9 bytes, that for alignment 
> reasons is very likely to be rounded up to 16.

No, to store an empty string you need one byte, an object of type char
holding the value 0.

To store a pointer to an empty string you need enough memory to hold a
pointer.

> You save 16 bytes everywhere you need an empty string!
>
> Empty strings do not use any storage. More efficient, in my opinion.

If an application uses enough empty strings for memory usage to be an
issue, it can establish its own convention.

>>> 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.)  
>
> Yes, we can always not improve anything by saying: we got until here 
> without this improvement, so let's go on.
>
> Why improve things? The fact is, we live without "XXX" so let's leave 
> everything as it is now, forever.
>
> I do not expect anything else from you anyway.

It is a fact that we've gotten along without a language-defined bit
bucket so far.  I never said that implies that we can't add it.
I also acknowledged that it might be a useful feature to add and
discussed alternatives.

Why must you make this personal?

>> 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.
>
> In systems where /dev/null doesn't exist we can have an emulator of course!
>
> Emulating /dev/null is so easy!
>
> All reads returnb EOF and all writes are NOPs.
>
> Not rocket sicence really.

Sure, it can be emulated -- but why bother?

>> 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.
>
> As an example, the default value would be to open for read and write if 
> the file doesn't exist, and to open for reading setting the file pointer 
> at the start of the file if it exists.
>
> Logical isn't it?

If that's useful, then define a new mode string with those semantics.
Why must it be the empty string?

> That would save terabytes of "r" strings in the executables in C.

Terabytes.  Right.

>>> 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.
>
> Not language functions like strlen, etc. The behavior of those function 
> is what should be changed.

I disagree.  I don't think it would be a good idea to define
strlen(NULL) to return 0.

>> I don't see much benefit in changing the standard library's behavior.
>
> Sure. Do not touch the standards, do not change anything, the old song 
> that you sing since several years.

I'm sure that's the song I've been singing in your head, but I haven't
said it in real life.

> I am not so keen to do this, but it make sense.
>
>> 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.
>
> You misunderstand. It wouldn't be errors but just different syntax.

No, I didn't misunderstand, I was making a different point.

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