www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - md5 hashing acting strangly?

reply "Sean Campbell" <sycam.inc gmail.com> writes:
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?
Jul 16 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Jul 16 2014
parent reply "Kagamin" <spam here.lot> writes:
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?
Jul 16 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Jul 16 2014
parent reply "Kagamin" <spam here.lot> writes:
Report for the problem when a temporary fixed-size array is 
assigned to a slice, which is escaped.
Jul 16 2014
parent reply "bearophile" <bearophileHUGS lycos.com> writes:
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
Jul 16 2014
next sibling parent reply "Kagamin" <spam here.lot> writes:
I have a more pragmatic view. Do you know the issue number?
Jul 16 2014
parent reply =?UTF-8?B?QWxpIMOHZWhyZWxp?= <acehreli yahoo.com> writes:
On 07/16/2014 06:31 AM, Kagamin wrote:

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


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

Ali
Jul 16 2014
parent "Kagamin" <spam here.lot> writes:
On Wednesday, 16 July 2014 at 18:17:25 UTC, Ali Çehreli wrote:

 On 07/16/2014 06:31 AM, Kagamin wrote:

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


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


This is not about temporary. Well, looks like it's not there.
Jul 17 2014
prev sibling next sibling parent "Kagamin" <spam here.lot> writes:
Aren't these your words: fixing as many errors as possible always 
helps even if we don't fix all errors?
Jul 16 2014
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
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?
Jul 16 2014
parent "bearophile" <bearophileHUGS lycos.com> writes:
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
Jul 16 2014