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?
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
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 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?
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?
I have a more pragmatic view. Do you know the issue number?
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?
Report for the problem when a temporary fixed-size array is assigned to a slice, which is escaped.
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?
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?
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