www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - "".dup is null

reply Qian Xu <quian.xu stud.tu-ilmenau.de> writes:
Hi All,

The following code will throw an exception: 
  char[] s;
  assert( s.dup  is null); // OK
  assert("".dup !is null); // FAILED

"".dup is expectly also an empty string. 
Is this a compiler bug?

--Qian
May 04 2009
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 04 May 2009 09:46:57 -0400, Qian Xu <quian.xu stud.tu-ilmenau.de>  
wrote:


 Hi All,

 The following code will throw an exception:
   char[] s;
   assert( s.dup  is null); // OK
   assert("".dup !is null); // FAILED

 "".dup is expectly also an empty string.
 Is this a compiler bug?


I think you might have a bug?

"".dup is the same as s.dup, not sure why you would expect it to be  
not-null.

-Steve
May 04 2009
next sibling parent Qian Xu <quian.xu stud.tu-ilmenau.de> writes:
Steven Schveighoffer wrote:


 On Mon, 04 May 2009 09:46:57 -0400, Qian Xu <quian.xu stud.tu-ilmenau.de>
 wrote:
 

 Hi All,

 The following code will throw an exception:
   char[] s;
   assert( s.dup  is null); // OK
   assert("".dup !is null); // FAILED

 "".dup is expectly also an empty string.
 Is this a compiler bug?


 
 I think you might have a bug?
 
 "".dup is the same as s.dup, not sure why you would expect it to be
 not-null.
 
 -Steve


They are not the same. s is null. "" is an empty string. empty string and
null are definitely two thing.
May 04 2009
prev sibling parent reply Qian Xu <quian.xu stud.tu-ilmenau.de> writes:
Steven Schveighoffer wrote:


 I think you might have a bug?
 
 "".dup is the same as s.dup, not sure why you would expect it to be
 not-null.
 
 -Steve


If I have not explained clearly. 
Here is the full code:

  char[] s;
  assert(s     is null);
  assert(s.dup is null);

  assert(""     !is null); // OK
  assert("".dup !is null); // FAILED

At least the last two lines behave not consistent. 
Either both are failed, or both are passed.
May 04 2009
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 04 May 2009 10:22:49 -0400, Qian Xu <quian.xu stud.tu-ilmenau.de>  
wrote:


 Steven Schveighoffer wrote:


 I think you might have a bug?

 "".dup is the same as s.dup, not sure why you would expect it to be
 not-null.

 -Steve


 If I have not explained clearly.
 Here is the full code:

   char[] s;
   assert(s     is null);
   assert(s.dup is null);

   assert(""     !is null); // OK
   assert("".dup !is null); // FAILED

 At least the last two lines behave not consistent.
 Either both are failed, or both are passed.



OK, your original post was this:

   assert( s.dup  is null); // OK
   assert("".dup !is null); // FAILED


The compiler always returns a null array if you dup an empty array.  The  
reason being: why allocate memory for something that is zero length?

If anything, the oddity is this line:

assert("" !is null);

But of course, no memory is allocated for literals, so at least needless  
memory allocation does not occur.

To be consistent, I think assert("" is null); should pass, but it's a  
minor inconsistency at best.

I usually never compare arrays to null for this reason...

-Steve
May 04 2009
parent reply Georg Wrede <georg.wrede iki.fi> writes:
Steven Schveighoffer wrote:

 On Mon, 04 May 2009 10:22:49 -0400, Qian Xu 
 <quian.xu stud.tu-ilmenau.de> wrote:
 

 Steven Schveighoffer wrote:


 I think you might have a bug?

 "".dup is the same as s.dup, not sure why you would expect it to be
 not-null.

 -Steve


 If I have not explained clearly.
 Here is the full code:

   char[] s;
   assert(s     is null);
   assert(s.dup is null);

   assert(""     !is null); // OK
   assert("".dup !is null); // FAILED

 At least the last two lines behave not consistent.
 Either both are failed, or both are passed.


 
 
 OK, your original post was this:
 
   assert( s.dup  is null); // OK
   assert("".dup !is null); // FAILED
 
 
 The compiler always returns a null array if you dup an empty array.  The 
 reason being: why allocate memory for something that is zero length?
 
 If anything, the oddity is this line:
 
 assert("" !is null);


If I remember correctly, string literals are stored with a null 
appended, so as to make them easier to use with OS calls, etc. Could it 
be that "" stores a 1-byte string, consisting with just this null? Then 
this behavior would be understandable.


 But of course, no memory is allocated for literals, so at least needless 
 memory allocation does not occur.
 
 To be consistent, I think assert("" is null); should pass, but it's a 
 minor inconsistency at best.
 
 I usually never compare arrays to null for this reason...
 
 -Steve
May 04 2009
parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Mon, 04 May 2009 12:09:09 -0400, Georg Wrede <georg.wrede iki.fi> wrote:


 If I remember correctly, string literals are stored with a null  
 appended, so as to make them easier to use with OS calls, etc. Could it  
 be that "" stores a 1-byte string, consisting with just this null? Then  
 this behavior would be understandable.


Yes, that makes complete sense, thanks.

-Steve
May 04 2009