void main() {
	pragma(msg,"bar".sizeof);
	size_t foo = 12;
	switch(foo) {
	case hashOf("bar"):
		break;
	}
}

I'm pretty sure this worked before. (htmld is full of these hash case statements.) But now, when I try to compile, it spits out errors like

druntime/import/object.d(3173): Error: pointer slice [0..16] exceeds allocated memory block [0..3]
druntime/import/object.d(3173):        called from here: hashOf(& arg[0..16], seed)
test.d(5):        called from here: hashOf("bar", 0LU)

I'm not sure, but I think "bar".sizeof is supposed to evaluate to 3 at compile time, rather than 16 regardless of the string's length.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

Please post bugs to bugzilla!

https://issues.dlang.org/enter_bug.cgi

On 7/26/2016 9:57 PM, cy via dmd-internals wrote:
> void main() {
>     pragma(msg,"bar".sizeof);
>     size_t foo = 12;
>     switch(foo) {
>     case hashOf("bar"):
>         break;
>     }
> }
>
> I'm pretty sure this worked before. (htmld is full of these hash case
> statements.) But now, when I try to compile, it spits out errors like
>
> druntime/import/object.d(3173): Error: pointer slice [0..16] exceeds allocated
> memory block [0..3]
> druntime/import/object.d(3173):        called from here: hashOf(& arg[0..16], seed)
> test.d(5):        called from here: hashOf("bar", 0LU)
>
> I'm not sure, but I think "bar".sizeof is supposed to evaluate to 3 at compile
> time, rather than 16 regardless of the string's length.
> _______________________________________________
> dmd-internals mailing list
> dmd-internals@puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

> On Jul 27, 2016, at 12:57 AM, cy via dmd-internals <dmd-internals@puremagic.com> wrote:
> 
> I'm not sure, but I think "bar".sizeof is supposed to evaluate to 3 at compile time, rather than 16 regardless of the string's length.

I think you have that backwards. “bar” is an immutable(char)[], which is a struct with a pointer and a size_t. Should be 16.

This may be a holdover from older compilers, when “bar” was actually typed as char[3]. Definitely seems like a bug in CTFE, please file.

Note, this compiles with latest released compiler, so it should be flagged a regression. I think the issue was there, but hashOf has gone through some changes recently for safety, so that probably uncovered the issue.

-Steve


_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

On Wednesday, 27 July 2016 at 05:53:35 UTC, Walter Bright wrote:
> Please post bugs to bugzilla!

Whoops, my bad. I was wondering where to post it.

On Thursday, 28 July 2016 at 13:15:28 UTC, Steven Schveighoffer wrote:
>> I'm not sure, but I think "bar".sizeof is supposed to evaluate to 3 at compile time, rather than 16 regardless of the string's length.
>
> I think you have that backwards. “bar” is an immutable(char)[], which is a struct with a pointer and a size_t. Should be 16.

Well, it would be more useful if it was a char[3]. Since the compiler can predict the string's length already, I don't know why they'd stop defining it as such. But if they don't anymore, I guess there's not much to be done about it.

> Note, this compiles with latest released compiler, so it should be flagged a regression.

I just updated on the 27th, with the last change to dmd on the 25th. I'll update again though, thanks. Good to know it's already fixed!

Admittedly, one should never have to do case hashOf("literal") since case "literal" already computes the hash of it so maybe it should be a bug submitted to htmld too. It may be slightly more efficient to _store_ an explicitly hashed string though, as you only have to hang onto the size_t hash, not the whole string.
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals

> On Jul 31, 2016, at 2:28 PM, cy via dmd-internals <dmd-internals@puremagic.com> wrote:
> 
> 
> On Thursday, 28 July 2016 at 13:15:28 UTC, Steven Schveighoffer wrote:
>> Note, this compiles with latest released compiler, so it should be flagged a regression.
> 
> I just updated on the 27th, with the last change to dmd on the 25th. I'll update again though, thanks. Good to know it's already fixed!

No, when I tested, it was broken on master (which is unreleased). But the latest released version did work. So it’s not already fixed, it’s already broken :)

-Steve
_______________________________________________
dmd-internals mailing list
dmd-internals@puremagic.com
http://lists.puremagic.com/mailman/listinfo/dmd-internals