D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 10724 - Allow slice of string literal to convert to const(char)*
Summary: Allow slice of string literal to convert to const(char)*
Status: RESOLVED FIXED
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: All All
: P2 enhancement
Assignee: yebblies
URL:
Keywords: pull
Depends on:
Blocks:
 
Reported: 2013-07-27 23:46 UTC by yebblies
Modified: 2013-10-16 21:33 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description yebblies 2013-07-27 23:46:27 UTC
The following code is perfectly safe because the slice happens at compile time, but the conversion is not allowed.

void main()
{
    const(char)* s = "abc"[0..$-1];
}
Comment 2 bearophile_hugs 2013-07-28 03:42:51 UTC
Implicit conversions introduce a bit of dangers in a language. They should be minimized.

Instead of this:
const(char)* s = "abc"[0..$-1];

What about this?
const(char)* s = "abc"[0..$-1].ptr;
Comment 3 yebblies 2013-07-28 03:52:45 UTC
(In reply to comment #2)
> Implicit conversions introduce a bit of dangers in a language. They should be
> minimized.
> 
> Instead of this:
> const(char)* s = "abc"[0..$-1];
> 
> What about this?
> const(char)* s = "abc"[0..$-1].ptr;

The conversion is only safe because the string literal is null-terminated.  Explicitly adding .ptr bypasses that, making it unsafe to rely on this.

Currently `"abc"[0..$-1]` gets const-folded to (essentially) `cast(string)"ab"`, and not for any reason I can see.  It should be just plain "ab", which can convert to a const cstring.

The only downside I can see is potential confusion that the above works, but this doesn't:
string str = "abc"[0..$-1];
const(char)* s = str;

But this is already present with plain string literals, as well as concatenation and probably others.
Comment 4 github-bugzilla 2013-07-28 16:47:38 UTC
Commits pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/a878588c71ea51e2365cd595dc38413700cc3d8a
Fix Issue 10724 - Allow slice of string literal to convert to const(char)*

https://github.com/D-Programming-Language/dmd/commit/e230276ee0703a3cdf92e16e1b9f388be44e9c54
Merge pull request #2392 from yebblies/issue10724

[DDMD] Fix Issue 10724 - Allow slice of string literal to convert to const(char)*
Comment 5 Andrej Mitrovic 2013-07-29 08:40:53 UTC
Just to clarify:

const(char)* a = "abc";
const(char)* b = "abc"[0..$-1];

Do a and b end up pointing to different memory addresses?
Comment 6 yebblies 2013-07-29 08:43:28 UTC
(In reply to comment #5)
> Just to clarify:
> 
> const(char)* a = "abc";
> const(char)* b = "abc"[0..$-1];
> 
> Do a and b end up pointing to different memory addresses?

Yes.
Comment 7 Luís Marques 2013-10-16 21:13:26 UTC
The following used not to work in v2.063.2:

    const a = "a";
    const b = a ~ "b";
    const(char)* output = b;

    $ Error: cannot implicitly convert expression ("ab") of type const(immutable(char)[]) to const(char)*

Although this worked:

    const b = "a" ~ "b";
    const(char)* output = b;

Now both work. I assume it was the fix for this issue (10724) that also fixed this? I say fixed because at first glance the old behavior seems wrong, but it seems such a basic statement that I wonder why this wasn't spotted before, or if I'm making a mistake. So please confirm this change in behavior was also desirable.
Comment 8 yebblies 2013-10-16 21:33:06 UTC
(In reply to comment #7)
> The following used not to work in v2.063.2:
> 
>     const a = "a";
>     const b = a ~ "b";
>     const(char)* output = b;
> 
>     $ Error: cannot implicitly convert expression ("ab") of type
> const(immutable(char)[]) to const(char)*
> 
> Although this worked:
> 
>     const b = "a" ~ "b";
>     const(char)* output = b;
> 
> Now both work. I assume it was the fix for this issue (10724) that also fixed
> this? I say fixed because at first glance the old behavior seems wrong, but it
> seems such a basic statement that I wonder why this wasn't spotted before, or
> if I'm making a mistake. So please confirm this change in behavior was also
> desirable.

All this patch changed was the 'committing' behavior of SliceExp constfolding.  Without a slice anywhere in there it doesn't look like this patch is the cause.

The code does appear to be valid as 'a' and 'b' are const variables with initializers known at compile time, so the const-folder can determine that 'output' is assigned a string literal and allow the conversion.  I would expect replacing any of them with a run-time determined value will prevent the conversion.