www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Template overloads involving `string` and `char[constant]` return

reply Johan Engelen <j j.nl> writes:
What's the bug in the following code:

```d
import std.digest.md;
import std.stdio;

pragma(inline, false) // just in case
string getHash()
{
     ubyte[16] hash = [1,2,3,4,5,6,6,78,8,8,7,7,6,3,2,3];
     string a = toHexString(hash);
     return a;
}

pragma(inline, false) // just in case
void destroystack()
{
     writeln("asd","asd","asd","asd","asd","asd");
}

void main()
{
     string a = getHash();
     destroystack();
     writeln(a);
}
```

Hint: when changing
```
     string a = toHexString(hash);
     return a;
```
to
```
     return toHexString(hash);
```
the compiler errors with:
`Error: escaping reference to stack allocated value returned by 
toHexString(hash)`.

So:
-  the documentation of toHexString says that the overloads 
returning a string return a GC allocated string
- the _implementation_ of `string toHexString(...)` does a `new 
char[16]`, so GC allocates.
- `string a = toHexString(hash);` calls `char[num*2] 
toHexString(...)` instead of `string toHexString(...)`.   OOPS.

https://issues.dlang.org/show_bug.cgi?id=16519

I don't know whether this is a compiler bug (choosing the wrong 
overload) or a Phobos bug (overloads don't work like that).
How are template overloads involving `string` and 
`char[constant]` return values supposed to work?

Still can't believe I am the first one to run into this, what am 
I doing wrong?

-Johan
Sep 21 2016
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 21 September 2016 at 12:07:31 UTC, Johan Engelen 
wrote:
     string a = toHexString(hash);
This is a pretty common pitfall (and IMO one of the most egregious design flaws in the language), I see it all the time. toHexString, when given a static array, returns a static array, but the language allows you to implicitly slice that into a pointer (mistaken design in any case, doubly so since it a stack pointer)... and moreover it is implicitly cast to immutable! So it will implicitly cast that char[x] to string in a LOT of places... and it is almost always wrong. If you passed `hash[]` it should then do what you want... so arguably the implicit slice rule is confusing you here too, I'd LOVE to kill that rule entirely.
 I don't know whether this is a compiler bug (choosing the wrong 
 overload) or a Phobos bug (overloads don't work like that).
It is neither, the compiler chose the right overload (remember, overloads are chosen based on the arguments alone, the type you specify for the variable holding the return value isn't a consideration there) and the implementation of each overload is correct. But the horribly wrong implicit slice and cast rules make it do the totally wrong thing while looking fine at first glance.
Sep 21 2016
next sibling parent reply Johan Engelen <j j.nl> writes:
On Wednesday, 21 September 2016 at 12:20:14 UTC, Adam D. Ruppe 
wrote:
 
 It is neither, the compiler chose the right overload (remember, 
 overloads are chosen based on the arguments alone, the type you 
 specify for the variable holding the return value isn't a 
 consideration there) and the implementation of each overload is 
 correct.
Wouldn't something like this be possible? `T toHexString(string toHexString(Order order = Order.increasing, LetterCase letterCase = LetterCase.upper, T)(.........) if (T == string)`
Sep 21 2016
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 21 September 2016 at 12:29:54 UTC, Johan Engelen 
wrote:
 Wouldn't something like this be possible?

 `T toHexString(string toHexString(Order order = 
 Order.increasing, LetterCase letterCase = LetterCase.upper, 
 T)(.........) if (T == string)`
I'm not sure what that's supposed to be.... but in any case, you'd still need to specify T somewhere in the call, the variable you are assigning the result to never does anything with regard to overloads or template args.
Sep 21 2016
parent Johan Engelen <j j.nl> writes:
On Wednesday, 21 September 2016 at 13:06:08 UTC, Adam D. Ruppe 
wrote:
 
 the variable you are assigning the result to never does 
 anything with regard to overloads or template args.
Gotcha, thanks.
Sep 21 2016
prev sibling parent reply Johan Engelen <j j.nl> writes:
On Wednesday, 21 September 2016 at 12:20:14 UTC, Adam D. Ruppe 
wrote:
 This is a pretty common pitfall (and IMO one of the most 
 egregious design flaws in the language), I see it all the time.
I write very little D code, so I guess it had to happen at some point then. Man, this is really bad :((
 toHexString, when given a static array, returns a static array, 
 but the language allows you to implicitly slice that into a 
 pointer (mistaken design in any case, doubly so since it a 
 stack pointer)... and moreover it is implicitly cast to 
 immutable!
Thanks for the explanation. It should really be mentioned in the documentation of toHexString, with an actual example instead of a unittest. The original code was doing: ``` MD5 md5; md5.start(); md5.put(cast(const(ubyte)[]) "some interesting data"); auto hash = md5.finish(); return toHexString!(LetterCase.lower)(hash); ``` I guess `ubyte[] hash = md5.finish();` would have fixed it too.
Sep 21 2016
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Wednesday, 21 September 2016 at 12:39:57 UTC, Johan Engelen 
wrote:
 It should really be mentioned in the documentation of 
 toHexString, with an actual example instead of a unittest.
Do you use my dpldocs.info? I add such notes there from time to time: http://dpldocs.info/experimental-docs/std.digest.digest.toHexString.1.html
 I guess `ubyte[] hash = md5.finish();` would have fixed it too.
Yes, though IMO that's still depending on the same language design flaw. I'd prefer to just explicitly pass `hash[]` to the function call so it is clear right there.
Sep 21 2016