[Bug 91] String literals not always properly zero-terminated

[via D.gnu]

http://bugzilla.gdcproject.org/show_bug.cgi?id=91

Jens Bauer <jens-bugzilla at gpio.dk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jens-bugzilla at gpio.dk

--- Comment #11 from Jens Bauer <jens-bugzilla at gpio.dk> ---
(In reply to Peter Remmers from comment #7)
> I might add, always adding a zero termination costs nothing apart from a few
> bytes in the data segment.
> 
> At the very least this is a performance issue, as GDC's toStringz(string)
> would always copy, and DMD's and LDC's would not.

Though this might be an old conversation, I'd like to add:

If your string resides in read-only memory, and you need to use it as a
zero-terminated string, then you will need to copy it to read/write memory, in
order to add the zero. After that, you can hand it to whichever function you
need to call.

Disadvantages:
1: On small microcontrollers - say those that have 1024 bytes of RAM and 8KB
Flash memory (eg. read-only memory), you'll very quickly run out of memory.
Thus it would be a good idea to have the zero included in the string in such
cases.
2: It's fairly easy to implement bugs in your code, if strings are not
zero-terminated automatically.

Advantages:
When you have very little read-only memory, then it may be possible to recycle
a strings where occurrences of smaller strings can be found within longer
strings.
-Unfortunately, many strings start with an uppercase letter.

"assignment missing"
"missing variable"
"variable not found"
"found '%s' when expecting '%s'"

I do not know, how realstic this compression/compacting is in the real world,
though, but it could be significant on small devices.

My suggestion would be:
By default, a zero-termination should be included.
If explicitly specified, the zero-termination should be excluded.
Then we'd have the safety from getting loads of bugs when writing 'late-night
code' and still be able to benefit from short strings and possibly compacting.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/d.gnu/attachments/20150405/37687793/attachment.html>