Thread overview
string literal error?
May 08, 2008
badmadevil
May 08, 2008
badmadevil
May 08, 2008
Simen Kjaeraas
May 08, 2008
badmadevil
May 08, 2008
Simen Kjaeraas
May 10, 2008
badmadevil
May 08, 2008
Hi, sorry if already discussed.

codes:
  string x = "bug?" ;
  string y = "bug?" ;
  string z = "bug?".reverse ;
  writefln("%s : %s : %s", x, y, z) ;
  x.reverse ;
  writefln("%s : %s : %s", x, y, z) ;

output - D 1.027 & 2.013:
>?gub : ?gub : ?gub
>bug? : bug? : bug?

Should x, y, z be independent to each others?
May 08, 2008
badmadevil wrote:
> Hi, sorry if already discussed.
> 
> codes:
>   string x = "bug?" ;
>   string y = "bug?" ;
>   string z = "bug?".reverse ;
>   writefln("%s : %s : %s", x, y, z) ;
>   x.reverse ;

same effect if x is replace with literal "bug?", ie.
  "bug?".reverse ;

>   writefln("%s : %s : %s", x, y, z) ;
> 
> output - D 1.027 & 2.013:
>  >?gub : ?gub : ?gub
>  >bug? : bug? : bug?
> 
> Should x, y, z be independent to each others?
May 08, 2008
On Thu, 08 May 2008 20:37:17 +0200, badmadevil <badmadevil@gmail.com> wrote:

> badmadevil wrote:
>> Hi, sorry if already discussed.
>>  codes:
>>   string x = "bug?" ;
>>   string y = "bug?" ;
>>   string z = "bug?".reverse ;
>>   writefln("%s : %s : %s", x, y, z) ;
>>   x.reverse ;
>
> same effect if x is replace with literal "bug?", ie.
>    "bug?".reverse ;
>
>>   writefln("%s : %s : %s", x, y, z) ;
>>  output - D 1.027 & 2.013:
>>  >?gub : ?gub : ?gub
>>  >bug? : bug? : bug?
>>  Should x, y, z be independent to each others?

This happens because .reverse does in-place reversal. The
correct way to do it would be:

  string x = "bug?".idup;
  string y = "bug?".idup;
  string z = "bug?".idup.reverse;
  writefln(x,y,z);
  x.reverse;
  writefln(x,y,z);
  writefln(typeof("bug?").stringof);

Now, seeing as the array contents are invariant in this example,
.reverse is not following the D rules of conduct. (i.e. it's buggy)

-- Simen
May 08, 2008
Simen Kjaeraas wrote:
> On Thu, 08 May 2008 20:37:17 +0200, badmadevil <badmadevil@gmail.com> wrote:
> 
>> badmadevil wrote:
>>> Hi, sorry if already discussed.
>>>  codes:
>>>   string x = "bug?" ;
>>>   string y = "bug?" ;
>>>   string z = "bug?".reverse ;
>>>   writefln("%s : %s : %s", x, y, z) ;
>>>   x.reverse ;
>>
>> same effect if x is replace with literal "bug?", ie.
>>    "bug?".reverse ;
>>
>>>   writefln("%s : %s : %s", x, y, z) ;
>>>  output - D 1.027 & 2.013:
>>>  >?gub : ?gub : ?gub
>>>  >bug? : bug? : bug?
>>>  Should x, y, z be independent to each others?
> 
> This happens because .reverse does in-place reversal. The
> correct way to do it would be:
> 
>   string x = "bug?".idup;
>   string y = "bug?".idup;
>   string z = "bug?".idup.reverse;
>   writefln(x,y,z);
>   x.reverse;
>   writefln(x,y,z);
>   writefln(typeof("bug?").stringof);
> 
> Now, seeing as the array contents are invariant in this example,
> .reverse is not following the D rules of conduct. (i.e. it's buggy)
> 

I see, .reverse is buggy in D2 situation.

How about D1?
string in D1 is just alias of char[]. It should be valid in the case
of x.reverse. (x is of type char[])

It seems that the reason x,y,z reference to same string literal is to
reduce bloated string data in the .exe (repeated literal array of other
type, eg. integer, may not be reduced).
dup/idup each literal array may avoid such bug, but would it be handy
that idup/dup be implictly called during runtime?

(btw, the title should read "string literal bug?")

> -- Simen
May 08, 2008
badmadevil <badmadevil@gmail.com> wrote:

> I see, .reverse is buggy in D2 situation.
>
> How about D1?
> string in D1 is just alias of char[]. It should be valid in the case
> of x.reverse. (x is of type char[])
>
> It seems that the reason x,y,z reference to same string literal is to
> reduce bloated string data in the .exe (repeated literal array of other
> type, eg. integer, may not be reduced).
> dup/idup each literal array may avoid such bug, but would it be handy
> that idup/dup be implictly called during runtime?

Consider the case where you have a 2MB string literal (for some weird
reason), with 1K references to it. Would you like for the program to call
.dup on each of those? A bit hypothetical, I know, but it should highlight
the problem. I believe for D1, COW (copy on write) is how things should
work. In other words, the correct D1 program would look like this:

  string x = "bug?";
  string y = "bug?";
  string z = "bug?".dup.reverse; // copy because we're changing it
  writefln(x,y,z);
  x.dup.reverse; // copy because we're changing it
  writefln(x,y,z);
  writefln(typeof("bug?").stringof);

In the context of D1, I can see how non-duped string literals may be a
source of bugs, indeed. This (except that it does not work :p) is one of
the reasons I like D2's invariant strings.

-- Simen
May 10, 2008
Simen Kjaeraas wrote:
> badmadevil <badmadevil@gmail.com> wrote:
> 
>> I see, .reverse is buggy in D2 situation.
>>
>> How about D1?
>> string in D1 is just alias of char[]. It should be valid in the case
>> of x.reverse. (x is of type char[])
>>
>> It seems that the reason x,y,z reference to same string literal is to
>> reduce bloated string data in the .exe (repeated literal array of other
>> type, eg. integer, may not be reduced).
>> dup/idup each literal array may avoid such bug, but would it be handy
>> that idup/dup be implictly called during runtime?
> 
> Consider the case where you have a 2MB string literal (for some weird
> reason), with 1K references to it. Would you like for the program to call
> .dup on each of those? A bit hypothetical, I know, but it should highlight


Got the idea. Thank you!

> the problem. I believe for D1, COW (copy on write) is how things should
> work. In other words, the correct D1 program would look like this:
> 
>   string x = "bug?";
>   string y = "bug?";
>   string z = "bug?".dup.reverse; // copy because we're changing it
>   writefln(x,y,z);
>   x.dup.reverse; // copy because we're changing it
>   writefln(x,y,z);
>   writefln(typeof("bug?").stringof);
> 
> In the context of D1, I can see how non-duped string literals may be a
> source of bugs, indeed. This (except that it does not work :p) is one of
> the reasons I like D2's invariant strings.
> 
> -- Simen