http://d.puremagic.com/issues/show_bug.cgi?id=8229
--- Comment #2 from timon.g...@gmx.ch 2012-06-12 10:55:45 PDT --- (In reply to comment #1) > This behaviour is intentional. Pointer operations are strictly checked in > CTFE. > It's the same as doing > > int n = 0; > char c = ""[n]; > > which generates an array bounds error at runtime. > I think that would be stretching it too far. It is more like: auto s = ['\0']; auto q = s[0..0]; char c = *q.ptr; Which works fine at runtime and during CTFE. > Is the terminating null character still in the spec? A long time ago it was in > there, but now I can only find two references to it in the current spec (in > 'arrays' and in 'interfacing to C'), and they both relate to printf. > > The most detailed is in 'interface to C', which states: > "string literals, when they are not part of an initializer to a larger data > structure, have a '\0' character helpfully stored after the end of them." > > which is pretty weird. These funky semantics would be difficult to implement > in > CTFE, I guess this is from D1 times, when string literals were static arrays, and doesn't apply anymore. > and I doubt they are desirable. Here's an example: > > const(char)[] foo(char[] s) { return "abc" ~ s; } > > immutable bar = foo("xyz"); // becomes a string literal when it leaves CTFE > Well, this is not specified afaics. > bool baz() > { > immutable bar2 = foo("xyz"); // local variable, so isn't a string literal. > > return true; > } > static assert(baz()); > > ---> bar is zero-terminated, bar2 is not, even though they had the same > assignment. When does this magical trailing zero get added? > This is exactly the behavior that is observed at runtime. If it is undesirable, then that is a distinct issue that should be investigated. It would certainly be desirable to have consistent behavior at compile time and at runtime, but this is not a top-priority issue. > I think you could reasonably interpret the spec as meaning that a trailing > zero > is added to the end of string literals by the linker, not by the compiler. > It's > only in CTFE that you can tell the difference. In this case, the spec should definitely be fixed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------