[Issue 8229] string literals are not zero-terminated during CTFE

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=8229



--- Comment #2 from timon.gehr at 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: -------