www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Slicing bug (and not just bits this time)

reply Arcane Jill <Arcane_member pathlink.com> writes:
Try this:

       ubyte s[10];
       ubyte[] t = s[0..0];
       if (t)
       {
           printf("t not empty\n");
       }

The problem is that expression s[i..j] yeilds a slice which is not well formed. It has a length field of zero, but a pointer field which is non-zero (actually the address of s[i]. Thus, expressions like if (s[i..j]) will NOT test as false if i == j. The current workaround is to repace "if (t)" with "if (t.length != 0)". Arcane Jill
Jun 12 2004
parent reply Norbert Nemec <Norbert.Nemec gmx.de> writes:
Arcane Jill wrote:

 Try this:
 
       ubyte s[10];
       ubyte[] t = s[0..0];
       if (t)
       {
           printf("t not empty\n");
       }

The problem is that expression s[i..j] yeilds a slice which is not well formed. It has a length field of zero, but a pointer field which is non-zero (actually the address of s[i]. Thus, expressions like if (s[i..j]) will NOT test as false if i == j. The current workaround is to repace "if (t)" with "if (t.length != 0)".

I'm not sure this is a bug or a feature. Of course, a zero-length array reference cannot be indexed without getting an out-of-range exception. But I'm not really sure whether it should be considered identical to null.
Jun 13 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <cahmcb$92$1 digitaldaemon.com>, Norbert Nemec says...
 The problem is that expression s[i..j] yeilds a slice which is not well
 formed. It has a length field of zero, but a pointer field which is
 non-zero (actually the address of s[i]. Thus, expressions like if
 (s[i..j]) will NOT test as false if i == j.
 
 The current workaround is to repace "if (t)" with "if (t.length != 0)".

I'm not sure this is a bug or a feature. Of course, a zero-length array reference cannot be indexed without getting an out-of-range exception. But I'm not really sure whether it should be considered identical to null.

Except that according to the D website at http://www.digitalmars.com/d/cppstrings.html, it says explicitly, and I quote:
Checking For Empty Strings
C++ strings use a function to determine if a string is empty:

    string str;
    if (str.empty())
        // string is empty

In D, an empty string is just null:

    char[] str;
    if (!str)
        // string is empty

So either the documentation is in error, or it's a bug. Arcane Jill
Jun 13 2004
parent reply Hauke Duden <H.NS.Duden gmx.net> writes:
Arcane Jill wrote:
 In article <cahmcb$92$1 digitaldaemon.com>, Norbert Nemec says...
 
The problem is that expression s[i..j] yeilds a slice which is not well
formed. It has a length field of zero, but a pointer field which is
non-zero (actually the address of s[i]. Thus, expressions like if
(s[i..j]) will NOT test as false if i == j.

The current workaround is to repace "if (t)" with "if (t.length != 0)".

I'm not sure this is a bug or a feature. Of course, a zero-length array reference cannot be indexed without getting an out-of-range exception. But I'm not really sure whether it should be considered identical to null.

Except that according to the D website at http://www.digitalmars.com/d/cppstrings.html, it says explicitly, and I quote:
Checking For Empty Strings
C++ strings use a function to determine if a string is empty:

   string str;
   if (str.empty())
       // string is empty

In D, an empty string is just null:

   char[] str;
   if (!str)
       // string is empty

So either the documentation is in error, or it's a bug. Arcane Jill

Hmmm. If this is the case then I think it is a mistake. A null string is different from an empty string. One means the absence of a string and the other means that the string has length 0. This is an important difference. For example, passing null for a string argument usually means "use the default". That kind of semantics would be impossible if empty strings are also valid values. Hauke
Jun 13 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
On Sun, 13 Jun 2004 19:39:48 +0200, Hauke Duden <H.NS.Duden gmx.net> wrote:
 Arcane Jill wrote:
 In article <cahmcb$92$1 digitaldaemon.com>, Norbert Nemec says...

 The problem is that expression s[i..j] yeilds a slice which is not 
 well
 formed. It has a length field of zero, but a pointer field which is
 non-zero (actually the address of s[i]. Thus, expressions like if
 (s[i..j]) will NOT test as false if i == j.

 The current workaround is to repace "if (t)" with "if (t.length != 
 0)".

I'm not sure this is a bug or a feature. Of course, a zero-length array reference cannot be indexed without getting an out-of-range exception. But I'm not really sure whether it should be considered identical to null.

Except that according to the D website at http://www.digitalmars.com/d/cppstrings.html, it says explicitly, and I quote:
 Checking For Empty Strings
 C++ strings use a function to determine if a string is empty:

   string str;
   if (str.empty())
       // string is empty

 In D, an empty string is just null:

   char[] str;
   if (!str)
       // string is empty

So either the documentation is in error, or it's a bug. Arcane Jill

Hmmm. If this is the case then I think it is a mistake. A null string is different from an empty string. One means the absence of a string and the other means that the string has length 0.

Agreed, we need both.
 This is an important difference. For example, passing null for a string 
 argument usually means "use the default". That kind of semantics would 
 be impossible if empty strings are also valid values.

I think it is logical that s[0..0] returns an empty string and not null. I think the docs need an update. The existing example is good as a test for null but it should be noted that empty strings can exist and how to get them. if (!str) //tests for null if (str.length == 0) //tests for null and empty Regan. -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 13 2004
parent "Vathix" <vathixSpamFix dprogramming.com> writes:
 Hmmm. If this is the case then I think it is a mistake. A null string is
 different from an empty string. One means the absence of a string and
 the other means that the string has length 0.

Agreed, we need both.

I always test s.length to see if it contains 0 elements. When I want to see if it's null I use s === null . if(s) was never reliable for me.
Jun 13 2004