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

Groups > comp.lang.c > #123231 > unrolled thread

NULL as the empty string

Back to article view | Back to comp.lang.c

Contents

  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

Page 1 of 5  [1] 2 3 4 5  Next page →

#123231 — NULL as the empty string

Whaat would happen if we decide to give meaning to NULL?

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!

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.

NULL could mean "empty string" or "Use the default value" or many other 
useful information, using zero storage...

What do you think?

[toc] | [next] | [standalone]

#123235

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"

[toc] | [prev] | [next] | [standalone]

#123240

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.

You save 16 bytes everywhere you need an empty string!

Empty strings do not use any storage. More efficient, in my opinion.

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

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

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

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

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

[toc] | [prev] | [next] | [standalone]

#123245

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"

[toc] | [prev] | [next] | [standalone]

#123253

Le 22/11/2017 à 01:02, Keith Thompson a écrit :
> jacobnavia <jacob@jacob.remcomp.fr> writes:
>> Le 22/11/2017 à 00:16, Keith Thompson a écrit :
>>> jacobnavia <jacob@jacob.remcomp.fr> writes:

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

GREAT! Thompson.

So, let's add it up pleeeeeeze?

In a 64 bit implementation you need 1 byte for the actual string and 8 
for storing a pointer.

That makes nine. You are saying exactly the same thing as I am saying. 
Aren't you ashamed ?

Speaking like the navia guy?

:-)

> Why must you make this personal?
> 

Because you attitude in all these discussions. Why change anything to 
our god given standard?

[SNIP]

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

OF COURSE.

I have heard that for so long that is now music in my ears.

[toc] | [prev] | [next] | [standalone]

#123263

jacobnavia <jacob@jacob.remcomp.fr> writes:
[SNIP]

Sorry, I thought you were looking for feedback on your ideas.

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

[toc] | [prev] | [next] | [standalone]

#123251

On Wed, 22 Nov 2017 00:38:57 +0100, jacobnavia
<jacob@jacob.remcomp.fr> wrote:

>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.
>
>You save 16 bytes everywhere you need an empty string!
>
>Empty strings do not use any storage. More efficient, in my opinion.


Wouldn't it be easier to just define a new macro, say EMPTYSTRING, and
have that point at a nul?  Total cost one pointer value and a byte to
point to.
FWIW, I don't consider the difference between no object, and an empty
object to be irrelevant.  Although I agree that in many string
handling cases, the two are usefully the same.

[toc] | [prev] | [next] | [standalone]

#123259

In article <ov2deh$r41$1@dont-email.me>, jacobnavia <jacob@jacob.remcomp.fr> 
wrote:

> 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.
> 
> You save 16 bytes everywhere you need an empty string!

My old laptop has four gigabytes of real memory and however many tens of 
gigabytes until the boot disk is filled with swap files.

I'm not going to worry about 16 bytes.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.    @
'I desire mercy, not sacrifice.'                                    /|\
I'm saving up to buy the Donald a blue stone      This post         / \
from Metebelis 3. All praise the Great Don!       insults Islam.  Mohammed

[toc] | [prev] | [next] | [standalone]

#123287

On 22/11/17 00:38, jacobnavia wrote:
> 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?
>>
<snip>
>> 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?

Not to me it isn't.  If I want to open a file for reading, and that file
doesn't exist, the last thing I would like is for the
compiler/library/system to automatically create it and open it for
writing.  And if I want to open a file for writing and it /does/ exist,
then the last thing I want is for it to be opened as read-only.

In other words, such a default here is absolutely useless.

A different default - like NULL being the same as "r" - might have some use.

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

What sort of program is going to open /billions/ of files?  And with the
tools I use at least, if I use the string "r" more than once in the same
executable, these strings are combined by the linker - they take /two/
bytes (for the 'r' and the '\0') no matter how many copies exist in the
program.

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

You can pick what value you give for strlen(NULL).  The standards don't
define it - your compiler and/or library may choose a value if you think
it helps your users.  No changes are needed.

[toc] | [prev] | [next] | [standalone]

#123243

On Tuesday, November 21, 2017 at 5:16:29 PM UTC-6, Keith Thompson wrote:
> 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.

In some APIs it is necessary to have a means of returning a string that the
caller is responsible for freeing.  There are three ways I can see for
handling null strings:

    1. Have the function allocate a new heap object and return a pointer
       to a zero byte contained therein.

    2. Have the function use a null pointer as a special value that
       represents and empty string, and have the "free string" function
       ignore null references.

    3. Return a pointer to a static object, and have the "free string"
       function silently ignore requests to free that object.

Personally, I would favor approach #3, since it could cheaply be extended
to efficiently handle not only empty strings, but also an arbitrary number
of other string constants as well (e.g. one might pre-allocate 127 objects
for single-character ASCII strings, or provide a way of requesting that
string literals go into a certain link region, have a function which will
return 1 for objects in that region and 0 for other objects, and then have
an strdup-like function which will return the passed-in pointer if it is
within that region, and otherwise create a new string object and copy the
one identified by the pointer.  The string-free function would use the same
means of testing whether a pointer was within the special static-string
region and refrain from trying to free any pointers that are.

Even though I prefer approach #3, the Windows Common Object Model uses
approach #2.  Such a convention is, btw, somewhat analogous to the way that
some implementations of malloc()-family functions return a null pointer for
zero-size allocations and then ignore null pointers passed to free().  Not
a bad approach *if* an implementation where malloc() returns null also
defines other null-related behaviors in suitable fashion.

[toc] | [prev] | [next] | [standalone]

#123249

Le 22/11/2017 à 00:57, supercat@casperkitty.com a écrit :

> In some APIs it is necessary to have a means of returning a string that the
> caller is responsible for freeing.  There are three ways I can see for
> handling null strings:
> 
>      1. Have the function allocate a new heap object and return a pointer
>         to a zero byte contained therein.
> 
>      2. Have the function use a null pointer as a special value that
>         represents and empty string, and have the "free string" function
>         ignore null references.
> 
>      3. Return a pointer to a static object, and have the "free string"
>         function silently ignore requests to free that object.
> 
> Personally, I would favor approach #3, since it could cheaply be extended
> to efficiently handle not only empty strings, but also an arbitrary number
> of other string constants as well (e.g. one might pre-allocate 127 objects
> for single-character ASCII strings, or provide a way of requesting that
> string literals go into a certain link region, have a function which will
> return 1 for objects in that region and 0 for other objects, and then have
> an strdup-like function which will return the passed-in pointer if it is
> within that region, and otherwise create a new string object and copy the
> one identified by the pointer.  The string-free function would use the same
> means of testing whether a pointer was within the special static-string
> region and refrain from trying to free any pointers that are.
> 

Incredible. I was thinking in a very similar thing. Suppose all values 
from 0 to 1024 (say) are reserved for the program and index a table of 
strings. For instance

432 would mean "This is the 432th string in the table"

This would allow easy internationalization since the table could be 
written in several languages. Using the same code your program switches 
from english to french or whatever.

> Even though I prefer approach #3, the Windows Common Object Model uses
> approach #2.  Such a convention is, btw, somewhat analogous to the way that
> some implementations of malloc()-family functions return a null pointer for
> zero-size allocations and then ignore null pointers passed to free().  Not
> a bad approach *if* an implementation where malloc() returns null also
> defines other null-related behaviors in suitable fashion.
> 

free(NULL) is legal. There is no problem there.

[toc] | [prev] | [next] | [standalone]

#123343

On Tuesday, November 21, 2017 at 6:06:48 PM UTC-6, jacobnavia wrote:
> Le 22/11/2017 à 00:57, supercat@casperkitty.com a écrit :
> >      3. Return a pointer to a static object, and have the "free string"
> >         function silently ignore requests to free that object.
> > 
> > Personally, I would favor approach #3, since it could cheaply be extended
> > to efficiently handle not only empty strings, but also an arbitrary number
> > of other string constants as well (e.g. one might pre-allocate 127 objects
> > for single-character ASCII strings, or provide a way of requesting that
> > string literals go into a certain link region, have a function which will
> > return 1 for objects in that region and 0 for other objects, and then have
> > an strdup-like function which will return the passed-in pointer if it is
> > within that region, and otherwise create a new string object and copy the
> > one identified by the pointer.  The string-free function would use the same
> > means of testing whether a pointer was within the special static-string
> > region and refrain from trying to free any pointers that are.
> > 
> 
> Incredible. I was thinking in a very similar thing. Suppose all values 
> from 0 to 1024 (say) are reserved for the program and index a table of 
> strings. For instance
> 
> 432 would mean "This is the 432th string in the table"
> 
> This would allow easy internationalization since the table could be 
> written in several languages. Using the same code your program switches 
> from english to french or whatever.

I wasn't expecting table items to be accessed via index; instead, if a
compiler marked all string literals with a request to put them into a
STRLIT section, a linker defined pointers (e.g.) __LNKSTART_STRLIT and
__LNKEND_STRLIT to the beginning and addresses of the STRLIT section,
and a platform supported a universal pointer ranking, then code

   doSomething("Fred");

would pass the address of a string located somewhere between
__LNKSTART_STRLIT and __LNKEND_STRLIT.

> > Even though I prefer approach #3, the Windows Common Object Model uses
> > approach #2.  Such a convention is, btw, somewhat analogous to the way that
> > some implementations of malloc()-family functions return a null pointer for
> > zero-size allocations and then ignore null pointers passed to free().  Not
> > a bad approach *if* an implementation where malloc() returns null also
> > defines other null-related behaviors in suitable fashion.
> 
> free(NULL) is legal. There is no problem there.

Yes, but calling free() on a pointer which is neither NULL nor the base
address of a "malloc-ation" will generally cause badness.  The goal here
would be to have a function that does nothing when given any address
between __LNKSTART_STRLIT and __LNKEND_STRLIT.

Some other platforms might not be able to allocate a section particularly
for string literals, but may be able to guarantee that all const-qualified
objects of static duration are below a certain address (e.g. because all
such objects have to fit, along with the code, in an 8Kx8 EPROM chip).
That would be fine too.  Simply change the "free()" function to ignore
any address located within ROM.

Using approach #2 rather than #3 offers two advantages I can see:

1. On many platforms, code to load zero will be smaller and faster than
   code to load some other constant value.

2. On some platforms it's useful to load code off disk and run it
   within the current execution context.  If empty strings are
   represented as NULL, such code could return empty strings without
   having to know the address of a static empty string object.  If
   some other address is needed, the loaded function would need to
   have some way of knowing what it is.  Note that if the function
   is loaded on the heap (as would be common), returning the address
   of a null string literal wouldn't work, since the caller would
   have no way of knowing whether it needed to be freed.
 
Windows DLLs have ways of accessing symbols for the current execution
context, so it would have been possible to have Windows define a
EMPTYSTRING symbol and require that DLLs which want to return an empty
string that the caller wouldn't have to copy nor free use that, but
that would have been a little bit awkward.  It seems a bit cleaner to
say something like:

   void releaseString(char *st)
   {
     if (st != NULL)
       free(st-8);  // Windows uses an allocator other than malloc() and
                    // would release string using a different deallocator
   }

   char copyAnyString(char *st)
   {
     if (st != NULL)
     {
       uint32_t len = strlen(st);
       char *retbase = malloc(9+len);
       memcpy(ret+4, st-4, len+5);
       *((uint32_t *)ret)=len; // Or however Windows defined buffer length
       return ret+8;
     }
   }

than

   void releaseString(char *st)
   {
     if (st != THE_ONE_AND_ONLY_STATIC_EMPTY_BSTRING)
       free(st-8);  // Windows uses an allocator other than malloc() and
                    // would release string using a different deallocator
   }
   char copyAnyString(char *st)
   {
     if (st != THE_ONE_AND_ONLY_STATIC_EMPTY_BSTRING)
     {
       uint32_t len = strlen(st);
       char *retbase = malloc(9+len);
       memcpy(ret+4, st-4, len+5);
       *((uint32_t *)ret)=len; // Or however Windows defined buffer length
       return ret+8;
     }
     else
       return st;
   }

Cleaner still might be a function to indicate whether a string should be
treated as static, but the Standard defines no means of telling whether
something is a string literal as opposed to something else.

[toc] | [prev] | [next] | [standalone]

#123344

On 2017-11-22, supercat@casperkitty.com <supercat@casperkitty.com> wrote:
>
> Cleaner still might be a function to indicate whether a string should be
> treated as static, but the Standard defines no means of telling whether
> something is a string literal as opposed to something else.

How about using proper type for string, not pointer to char...


-- 
press any key to continue or any other to quit...

[toc] | [prev] | [next] | [standalone]

#123345

On Wednesday, November 22, 2017 at 5:49:13 PM UTC-6, Melzzzzz wrote:
> On 2017-11-22, supercat@casperkitty.com <supercat@casperkitty.com> wrote:
> >
> > Cleaner still might be a function to indicate whether a string should be
> > treated as static, but the Standard defines no means of telling whether
> > something is a string literal as opposed to something else.
> 
> How about using proper type for string, not pointer to char...

Early implementations of C were much closer to freestanding
implementations than to hosted ones; even today, the only time
the concept of a zero-terminated string is relevant in a free-
standing implementations is when a string literal is used within
an expression that isn't an initializer for a fixed-size character
array.  A string literal used to initialize a character array of
unspecified size will make the size be one longer than the length
of the literal.  A string literal in other contexts will yield a
pointer to the specified sequence of characters followed by a zero
byte.

Nothing else in the language needs to treat string literals any
differently from any other char const*.

[toc] | [prev] | [next] | [standalone]

#123346

On 2017-11-22, supercat@casperkitty.com <supercat@casperkitty.com> wrote:
> On Wednesday, November 22, 2017 at 5:49:13 PM UTC-6, Melzzzzz wrote:
>> On 2017-11-22, supercat@casperkitty.com <supercat@casperkitty.com> wrote:
>> >
>> > Cleaner still might be a function to indicate whether a string should be
>> > treated as static, but the Standard defines no means of telling whether
>> > something is a string literal as opposed to something else.
>> 
>> How about using proper type for string, not pointer to char...
>
> Early implementations of C were much closer to freestanding
> implementations than to hosted ones; even today, the only time
> the concept of a zero-terminated string is relevant in a free-
> standing implementations is when a string literal is used within
> an expression that isn't an initializer for a fixed-size character
> array.  A string literal used to initialize a character array of
> unspecified size will make the size be one longer than the length
> of the literal.  A string literal in other contexts will yield a
> pointer to the specified sequence of characters followed by a zero
> byte.
>
> Nothing else in the language needs to treat string literals any
> differently from any other char const*.
No, I mean, why use char* for string, rather then struct {char*
data;usize_t len;} ?
Where data is allocated/deallocated with specialized functions?

-- 
press any key to continue or any other to quit...

[toc] | [prev] | [next] | [standalone]

#123413

On Wednesday, November 22, 2017 at 6:06:43 PM UTC-6, Melzzzzz wrote:
> On 2017-11-22, supercat@casperkitty.com <supercat@casperkitty.com> wrote:
> > Early implementations of C were much closer to freestanding
> > implementations than to hosted ones; even today, the only time
> > the concept of a zero-terminated string is relevant in a free-
> > standing implementations is when a string literal is used within
> > an expression that isn't an initializer for a fixed-size character
> > array.  A string literal used to initialize a character array of
> > unspecified size will make the size be one longer than the length
> > of the literal.  A string literal in other contexts will yield a
> > pointer to the specified sequence of characters followed by a zero
> > byte.
> >
> > Nothing else in the language needs to treat string literals any
> > differently from any other char const*.
> No, I mean, why use char* for string, rather then struct {char*
> data;usize_t len;} ?
> Where data is allocated/deallocated with specialized functions?

There are two main problems:

1. In many kinds of program, and a lot of strings get passed around by
   functions that don't do anything with them except pass them along to
   other functions, and many of the strings will be literals.  Passing
   around a pointer-plus-length structure costs twice as much as passing
   around a simple pointer.  Further, there's no nice way to create a
   static object associated with a string literal.

2. There's no single standard for what anything other than a zero-
   terminated string should look like, and thus code that needs to use
   a function in one library to create a string and then have a function
   in another library use it will often have to use an intermediate
   step to convert the data.

If C had a syntax to include a compile-time constant within a string
literal, then it would be practical to have a string type which would
point to the "hdr" field of any of the following:

    union string {
      struct shortString { unsigned char hdr; char text1[]; };
      struct medString { unsigned char hdr, h1; char text2[]; };
      struct longString { unsigned char hdr, h1,h2; char text3[]; };
      struct hugeString { unsigned char hdr, h1,h2,h3 char text4[]; };
      struct readableString { 
        unsigned char hdr;
        size_t length;
        char *const text;
      };
      struct writableString { 
        unsigned char hdr;
        size_t length;
        char *text;
        size_t allocSize;
        struct writablestring *root;
        size_t (**adjustAlloc)(int opcode, struct writableString *, ...);
      }
      ... as well as additional types that extend writableString.

Different values for hdr would identify which kind of string something was,
and library functions could convert any of them into either a readableString
or a writableString.  Code which needed to e.g. append text to a string
would not need to worry about whether the string was being stored directly
into a 64-byte buffer that had room for 63 characters, or a 1024-byte buffer
with room for 1022 characters, or in a dynamically-sized buffer that could
be relocated when necessary [code which was given e.g. a pointer to a
64-byte buffer which currently contained a 32-string, along with a pointer
to a writableString, would populate the latter:

    hdr = 255 [or some value indicating it's a struct of that type]
    length = 32
    text = address of string.text1
    allocSize = 63
    root = address of string.hdr
    adjustAlloc = A function which would perform length-adjustments or
      allocation-related operations in a fashion appropriate for a string
      stored in that fashion.

Such a design would make it possible to have a function that can either
populate a supplied buffer or allocate new space and return a pointer to
it, without having to worry about which behavior a caller wants (since
the caller would pass a pointer to a WritableString object that was set
up for the desired behavior).  If such a thing were standard, it could
help avoid a lot of code duplication.  Unfortunately, there's no useful
standard for such things.

[toc] | [prev] | [next] | [standalone]

#123422

Le 24/11/2017 à 02:31, supercat@casperkitty.com a écrit :
> Further, there's no nice way to create a
>     static object associated with a string literal

   1 typedef struct {unsigned long size; char *string} String;
   2 #define STR(a) { sizeof(a)-1,a}
   3 static String myString = STR("foo");

[toc] | [prev] | [next] | [standalone]

#123452

On Friday, November 24, 2017 at 2:42:25 AM UTC-6, jacobnavia wrote:
> Le 24/11/2017 à 02:31, supercat@casperkitty.com a écrit :
> > Further, there's no nice way to create a
> >     static object associated with a string literal
> 
>    1 typedef struct {unsigned long size; char *string} String;
>    2 #define STR(a) { sizeof(a)-1,a}
>    3 static String myString = STR("foo");

I had gotten a bit long-winded and then trimmed things back somewhat; a
point I trimmed is that string objects can be created by string literals
that appear within an expression, but Standard C would require that any
static object be created outside any expression that might use it, and
then be given an identifier which would serve no purpose outside that
expression.

Having to say:

     { MAKE_STRING(MyNameIsFred, "My name is Fred"); }
     retVal = someFunction(arg1, arg2, myNameIsFred, arg3, arg4);

is rather less convenient than simply being able to say:

     retVal = someFunction(arg1, arg2, MkStr("My name is Fred"), arg3, arg4);

From a storage perspective, it would be easy and efficient to have
string functions accept pointers that could either identify string
descriptors or a directly-stored fixed-length string or string buffer,
using the first byte of an object to identify what it is.  If one wants
to have a function like

   xsprintf(pstr dest, pstr fmt, ...);

which can automatically resize the destination buffer if the destination
string descriptor supports that, a string descriptor is going to have to
be somewhat large; using a descriptor for every string could get expensive.
On the other hand, it would be possible to have a function which when
given a string pointer and a pointer to a descriptor object, would either
fill in the supplied descriptor with the address, length, etc. of the
supplied string and return a pointer to that, or else simply return the
address of the original descriptor.

Creating static objects is doable if one doesn't mind having to give them
names and declare them at statement scope.  On the other hand, it's a lot
more convenient to be able to use string literals directly within
expressions and there's no good way to accomplish that.

[toc] | [prev] | [next] | [standalone]

#123275

On Tue, 2017-11-21, Keith Thompson wrote:
> 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.

To support the terabytes claim, I'd also like to see statistics from
an execution of a program, which performed a lot of malloc(1) calls in
order to store copies of empty strings.  My gut feeling is that it
doesn't happen that much.

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

There are a bunch of "ways to get a FILE*" that would be nice to have in C:
this, and files backed by string buffers for example.

[snip]

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#124016

On Tuesday, November 21, 2017 at 5:16:29 PM UTC-6, Keith Thompson wrote:
> 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.
> 

I think I get what Jacob is getting at - instead of NULL being a macro that expands
to a 0, have it be a special keyword with special, context-dependent semantics.  That is,
a call against strlen or strcmp with NULL would be interpreted differently by the compiler,
which would emit code that immediately returned a 0 or false result, without having to
actually evaluate anything, or store an actual empty string or pointer to an empty
string.

If that's what Jacob actually means, well, it feels to me like a solution to a problem that
isn't really a problem.  It's a micro-optimization.  Yes, if you have thousands of distinct
pointers to thousands of distinct empty strings, it will add up.  But, having thousands of 
distinct pointers to thousands of distinct empty strings sounds like a fairly esoteric use
case to begin with.  

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web