i have the following code
char[] Etag(string file){
	auto info = DirEntry(file);
	ubyte[16] hash = md5Of(to!string(info.timeLastAccessed.day)~
	                       to!string(info.timeLastAccessed.month)~
	                       to!string(~info.timeLastAccessed.year)~
	                       file);
	char[] hashstring = toHexString(hash);
	writeln(hashstring);
	return hashstring;
}
the proper hash string prints out in the console, but when i try to use the return value of Etag it becomes an obscure string?

Sean Campbell:

> i have the following code
> char[] Etag(string file){
> 	auto info = DirEntry(file);
> 	ubyte[16] hash = md5Of(to!string(info.timeLastAccessed.day)~
> 	                       to!string(info.timeLastAccessed.month)~
> 	                       to!string(~info.timeLastAccessed.year)~
> 	                       file);
> 	char[] hashstring = toHexString(hash);
> 	writeln(hashstring);
> 	return hashstring;
> }
> the proper hash string prints out in the console, but when i try to use the return value of Etag it becomes an obscure string?

As shown in the docs toHexString returns a fixed size array, that in D are values. With "char[] hashstring = " you are slicing a stack allocated variable, so Etag returns garbage. So you can write (note the starting lowercase):

auto etag(string file) {
...
> 	auto hashstring = toHexString(hash);
> 	writeln(hashstring);
> 	return hashstring;
> }

Such kind of bugs are impossible in Rust. Hopefully we'll eventually remove them from D too.

Bye,
bearophile

On Wednesday, 16 July 2014 at 12:15:34 UTC, bearophile wrote:
> Such kind of bugs are impossible in Rust. Hopefully we'll eventually remove them from D too.

Seems like a popular issue. Is there a bug report for it?

Kagamin:

> Seems like a popular issue.

Y
es, it is.

> Is there a bug report for it?

Bug report for what? To ask for [] to be used when you slice a fixed size array? This is in Bugzilla. Or perhaps you are asking for lifetime management of the data? This is currently discussed in the main D newsgroup in the "scope" threads.

Bye,
bearophile

Report for the problem when a temporary fixed-size array is assigned to a slice, which is escaped.

Kagamin:

> Report for the problem when a temporary fixed-size array is assigned to a slice, which is escaped.

I think this is already in Bugzilla. But the point is: you can't solve this problem locally and with small means. You need a principled solution (or no solution at all, as now) of memory area lifetime management, as discussed in the scope threads.

Bye,
bearophile

I have a more pragmatic view. Do you know the issue number?

Aren't these your words: fixing as many errors as possible always helps even if we don't fix all errors?

On 7/16/14, 10:22 AM, bearophile wrote:
> Kagamin:
>
>> Report for the problem when a temporary fixed-size array is assigned
>> to a slice, which is escaped.
>
> I think this is already in Bugzilla. But the point is: you can't solve
> this problem locally and with small means. You need a principled
> solution (or no solution at all, as now) of memory area lifetime
> management, as discussed in the scope threads.
>
> Bye,
> bearophile

When assigning a fixed size array to a slice, can't you just allocate memory and copy the data there (I mean, let the compiler do that in that case)? That would be safe, right?

Ary Borenszweig:

> When assigning a fixed size array to a slice, can't you just allocate memory and copy the data there (I mean, let the compiler do that in that case)? That would be safe, right?

Yes, using a .dup:

char[] hashstring = toHexString(hash).dup;

But the compiler should not do this by itself.

Bye,
bearophile