Editing Null-terminated string (section)

== Limitations ==
While simple to implement, this representation has been prone to errors and performance problems.

Null-termination has historically created [[computer insecurity|security problems]].<ref>{{cite journal|url= http://insecure.org/news/P55-07.txt |author=Rain Forest Puppy |title=Perl CGI problems |journal=Phrack Magazine |publisher=artofhacking.com |date=9 September 1999 |volume=9 |issue=55 |page=7 |access-date=3 January 2016}}</ref> A NUL inserted into the middle of a string will truncate it unexpectedly.<ref>{{Cite web|url=https://security.stackexchange.com/questions/48187/null-byte-injection-on-php|title = Null byte injection on PHP?}}</ref> A common bug was to not allocate the additional space for the NUL, so it was written over adjacent memory. Another was to not write the NUL at all, which was often not detected during testing because the block of memory already contained zeros. Due to the expense of finding the length, many programs did not bother before copying a string to a fixed-size [[Data buffer|buffer]], causing a [[buffer overflow]] if it was too long.

The inability to store a zero requires that text and binary data be kept distinct and handled by different functions (with the latter requiring the length of the data to also be supplied). This can lead to code redundancy and errors when the wrong function is used.

The speed problems with finding the length can usually be mitigated by combining it with another operation that is O(''n'') anyway, such as in <code>[[strlcpy]]</code>. However, this does not always result in an intuitive [[API]].