On 2/8/18 1:10 AM, Walter Bright wrote:
On 2/7/2018 9:45 PM, Ralph Doncaster wrote:
> While the fix is a huge improvement, it doesn't match the code
generated by the hex literals. hexString!"deadbeef" stores the
null-terminated string in the data section of the object file, while
x"deadbeef" only stores 4 bytes in the data section.
string s = x"deadbeef";
stores a null terminated string, too.
If you want only 4 bytes,
__gshared immutable char = hexString!"deadbeef";
just as you'd do for any string literal.
The extra data in the object file comes from the inclusion of the
hexStringImpl function, and from the template parameter (the symbol
_D3std4conv__T9hexStringVAyaa8_6465616462656566ZQBiyAa is in there as
well, which will always be larger than the actual string passed to
I also see the data in there twice for some reason.