https://d.puremagic.com/issues/show_bug.cgi?id=11837

           Summary: String literals should convert to const(void)*
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: yebblies@gmail.com


--- Comment #0 from yebblies <yebblies@gmail.com> 2013-12-29 03:08:31 EST ---
Code like this is perfectly valid:

memcmp(ptr, "abc");

But it fails in D because although string literals convert to const(char)*, and
const(char)* converts to const(void)*, string literals do not convert to
const(void)*

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11837


bearophile_hugs@eml.cc changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc


--- Comment #1 from bearophile_hugs@eml.cc 2013-12-28 08:33:27 PST ---
(In reply to comment #0)
> Code like this is perfectly valid:
> 
> memcmp(ptr, "abc");
> 
> But it fails in D because although string literals convert to const(char)*, and
> const(char)* converts to const(void)*, string literals do not convert to
> const(void)*

What are the advantages, disadvantages and possible risks of this change?

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11837



--- Comment #2 from yebblies <yebblies@gmail.com> 2013-12-29 03:37:19 EST ---
Code like this will compile:

memcmp(ptr, "abc", 3);

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11837


monarchdodra@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |monarchdodra@gmail.com


--- Comment #3 from monarchdodra@gmail.com 2013-12-28 12:54:42 PST ---
(In reply to comment #2)
> Code like this will compile:
> 
> memcmp(ptr, "abc", 3);

What's wrong with `memcmp(ptr, "abc".ptr, 3)`?

I seem to remember there is an issue with null termination in this kind of useage?

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11837



--- Comment #4 from yebblies <yebblies@gmail.com> 2013-12-29 14:53:09 EST ---
(In reply to comment #3)
> (In reply to comment #2)
> > Code like this will compile:
> > 
> > memcmp(ptr, "abc", 3);
> 
> What's wrong with `memcmp(ptr, "abc".ptr, 3)`?
> 

Adding .ptr looses the guarantee that the string will be 0-terminated.

eg
// enum x = "abc";
// immutable x = "abc";
auto x = "abc";

memcmp(ptr, x.ptr, 4); // oops, no guarantee x is 0-terminates, but the compiler has no way to know that's what you wanted.

> I seem to remember there is an issue with null termination in this kind of useage?

...?

The fact that string literals don't convert to const(void)* is IMO an annoying
special case.

This works:
const(char)* x = "askjldfg";
const(void)* y = x;

But this doesn't:
const(void)* y = "askjldfg";

Unless there's a good reason this has to be prevented...

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11837


yebblies <yebblies@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull


--- Comment #5 from yebblies <yebblies@gmail.com> 2013-12-29 16:24:04 EST ---
https://github.com/D-Programming-Language/dmd/pull/3044

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11837



--- Comment #6 from monarchdodra@gmail.com 2013-12-29 09:33:33 PST ---
(In reply to comment #4)
> (In reply to comment #3)
> > I seem to remember there is an issue with null termination in this kind of useage?
> 
> ...?

What I meant here is what you explained just above:

> > What's wrong with `memcmp(ptr, "abc".ptr, 3)`?
> > 
> 
> Adding .ptr looses the guarantee that the string will be 0-terminated.
> 
> eg
> // enum x = "abc";
> // immutable x = "abc";
> auto x = "abc";
> 
> memcmp(ptr, x.ptr, 4); // oops, no guarantee x is 0-terminates, but the compiler has no way to know that's what you wanted.

This may be a bit off topic, but what is the rationale behind this behavior? Why can't *all* string literals be 0 terminated, even if you explicitly extract a pointer out of them with ".ptr" ?

> The fact that string literals don't convert to const(void)* is IMO an annoying
> special case.
> 
> This works:
> const(char)* x = "askjldfg";
> const(void)* y = x;
> 
> But this doesn't:
> const(void)* y = "askjldfg";
> 
> Unless there's a good reason this has to be prevented...

If a string literal implicitly casts to "const(char)*", then it absolutely 100%
must be implicitly castable to "const(void)*". It only makes sense.

Though personally, I find that the fact that you can *implicitly* extract any pointer from a string literal to be suboptimal :/

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11837



--- Comment #7 from yebblies <yebblies@gmail.com> 2013-12-30 04:55:36 EST ---
(In reply to comment #6)
> > 
> > memcmp(ptr, x.ptr, 4); // oops, no guarantee x is 0-terminates, but the compiler has no way to know that's what you wanted.
> 
> This may be a bit off topic, but what is the rationale behind this behavior? Why can't *all* string literals be 0 terminated, even if you explicitly extract a pointer out of them with ".ptr" ?
> 

All string literals are guaranteed to be 0 terminated, even if you use .ptr on them.  The think is, manifest constants that expand to string literals also behave like this, so if this compiles you know it is safe:

printf(formatstr, ...);

But in this case, you can't tell:

printf(formatstr.ptr, ...); // was it really a string literal?

> 
> If a string literal implicitly casts to "const(char)*", then it absolutely 100%
> must be implicitly castable to "const(void)*". It only makes sense.
> 

Ok, good.  This is pretty much just convenience for porting c/c++ code, and removing what I see as an unnecessary limitation.

> Though personally, I find that the fact that you can *implicitly* extract any pointer from a string literal to be suboptimal :/

If it's safe, I don't see the harm.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11837


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com


--- Comment #8 from Walter Bright <bugzilla@digitalmars.com> 2013-12-29 23:09:38 PST ---
There's code in dmd to specifically disallow this. I believe the reason is because of function and template overloading. I'm not content with this change simply passing the existing test suite. It's a more subtle, substantive change than that.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11837



--- Comment #9 from yebblies <yebblies@gmail.com> 2013-12-30 18:37:33 EST ---
(In reply to comment #8)
> There's code in dmd to specifically disallow this. I believe the reason is because of function and template overloading.

Do you know what the actual problem is/was?  The code in dmd that disallows this is ancient, and may well address a problem that no longer exists.

Can you remember why you disabled it in the first place?  Did you document this anywhere?

As for overloading, this code works as expected as the conversion to
const(char)* is preferred.

import core.stdc.stdio;

void call(const(char)* str) { printf("const(char)*\n"); }
void call(const(void)* str) { printf("const(void)*\n"); }

void call(const(int)[] arr) { printf("const(int)[]\n"); }
void call(const(void)[] arr) { printf("const(void)[]\n"); }

void main()
{
    call("abc"); // prints const(char)*
    call([1, 2, 3]); // prints const(int)[]
}

> I'm not content with this change
> simply passing the existing test suite. It's a more subtle, substantive change
> than that.

What _would_ you be content with?  Unless someone can come up with an actual problem, putting this on hold is simply a waste of time.  If this does turn out to cause a regression, it can trivially be rolled back.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------