Content deleted Content added
No edit summary |
Move ref to where it should be |
||
Line 3:
The length of a C string is found by searching for the (first) NUL byte. This can be slow as it takes O(''n'') ([[linear time]]) with respect to the string length. It also means that a string cannot contain a NUL character (there is a NUL in memory, but it is after the last character, not "in" the string).
== History ==
Line 35 ⟶ 33:
While simple to implement, this representation has been prone to errors and performance problems.
The NUL 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 |work=Phrack Magazine |publisher=artofhacking.com |date=9 September 1999 |volume=9 |issue=55 |page=7 |accessdate=3 January 2016}}</ref> A NUL byte inserted into the middle of a string will truncate it unexpectedly.<ref>https://security.stackexchange.com/questions/48187/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 a NUL was already there by chance from previous use of the same block of memory. 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 NUL requires that string data 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.
|