On Saturday, 24 June 2017 at 14:18:33 UTC, ketmar wrote:
with the edge case when something like the code i posted below
managed to make `a` perfectly aligned with r/o area, and you
got segfault by accising out-of-bounds byte.
BTW, are you sure? AFAIU, it doesn't matter if the CTFE engine
returns a
non-null-terminated string expression, since the backend or
the glue layer
would write it to the object file as if it was a
null-terminated string.
immutable ubyte[2] a = [65,66];
enum string s = cast(string)a;
immutable ubyte[2] b = [67,68]; // just to show you that there
is no zero
void main () {
assert(s[$-1] == 0);
}
Thanks, I haven't considered immutable statically allocated
fixed-size arrays of chars.
Specifically, while mutable fixed-size arrays of both character
and non-character type
are common, I don't think immutable fixed-size char arrays are
much used compared to string literals and ctfe-derived strings.
I'm tempted to write in the documentation of my hypothetical
fastStringZ function that passing anything, but something
originating from a slice is UB, though I'm aware how
under-specified and hand-wavy this sounds.
On Saturday, 24 June 2017 at 14:21:23 UTC, ketmar wrote:
ketmar wrote:
p.s.: btw, druntime tries to avoid that edge case by not
checking for trailing out-of-bounds zero if string ends
exactly on dword boundary. it will miss some strings this way,
but otherwise it is perfectly safe.
oops. not druntime, phobos, in `std.string.toStringz()`.
Thanks, for some reason I assumed that toStringz always
conservatively copies the string, without even checking the code.
It looks like the more aggressive optimization was at some point
removed which is visible in this revision:
http://www.dsource.org/projects/phobos/changeset/101#file15
and later Andrei reintroduced it with the more conservative
heuristic:
https://github.com/dlang/phobos/commit/460c844b4fb9b96833871c111dd529d22129ab7c,
but I didn't manage to find any discussion about it.
***
But in any case, the null-terminated string was just an example
application.
I'm interested in a fast way to determine the "storage class" of
the memory
a slice or a pointer point to. I'm expecting some magic along the
lines of
checking the range of addresses that the rodata section resides
in memory.
Similar to how some allocators or the GC know if they own a range
of memory.
Any ideas on that?
***
