Re: md5 hashing acting strangly?
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.
Re: md5 hashing acting strangly?
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
Re: md5 hashing acting strangly?
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?
Re: md5 hashing acting strangly?
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
Re: md5 hashing acting strangly?
Report for the problem when a temporary fixed-size array is assigned to a slice, which is escaped.
Re: md5 hashing acting strangly?
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
Re: md5 hashing acting strangly?
I have a more pragmatic view. Do you know the issue number?
Re: md5 hashing acting strangly?
Aren't these your words: fixing as many errors as possible always helps even if we don't fix all errors?
Re: md5 hashing acting strangly?
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?
Re: md5 hashing acting strangly?
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
Re: md5 hashing acting strangly?
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
