https://d.puremagic.com/issues/show_bug.cgi?id=11837
--- Comment #6 from [email protected] 2013-12-29 09:33:33 PST --- (In reply to comment #4) > (In reply to comment #3) > > I seem to remember there is an issue with null termination in this kind of > > useage? > > ...? What I meant here is what you explained just above: > > What's wrong with `memcmp(ptr, "abc".ptr, 3)`? > > > > Adding .ptr looses the guarantee that the string will be 0-terminated. > > eg > // enum x = "abc"; > // immutable x = "abc"; > auto x = "abc"; > > memcmp(ptr, x.ptr, 4); // oops, no guarantee x is 0-terminates, but the > compiler has no way to know that's what you wanted. This may be a bit off topic, but what is the rationale behind this behavior? Why can't *all* string literals be 0 terminated, even if you explicitly extract a pointer out of them with ".ptr" ? > The fact that string literals don't convert to const(void)* is IMO an annoying > special case. > > This works: > const(char)* x = "askjldfg"; > const(void)* y = x; > > But this doesn't: > const(void)* y = "askjldfg"; > > Unless there's a good reason this has to be prevented... If a string literal implicitly casts to "const(char)*", then it absolutely 100% must be implicitly castable to "const(void)*". It only makes sense. Though personally, I find that the fact that you can *implicitly* extract any pointer from a string literal to be suboptimal :/ -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
