3 ms·

IMO, zero-terminated strings are, and always have been, a bad idea. Discriminating against a certain character instead of just regarding it as opaque blob of da

IMO, zero-terminated strings are, and always have been, a bad idea. Discriminating against a certain character instead of just regarding it as opaque blob of data will bite you in unexpected ways, and strlen() taking O(N) is another drawback. The string functions in the C standard library suck. bstring is a better alternative: http://bstring.cvs.sourceforge.net/viewvc/bstring/tree/bstrlib.txt?pathrev=HEAD http://bstring.cvs.sourceforge.net/viewvc/bstring/tree/bstrl... . Glib also has a good string library...

kbolino 15y ago
Something to bear in mind regarding non-standard string libraries: syscalls (like open[1] on POSIX or CreateFile[2] on Windows) use null-terminated strings, which means that you have to be careful about embedded nulls, no matter what library you use, when a string gets passed to a syscall somewhere in the chain. [1] http://pubs.opengroup.org/onlinepubs/000095399/functions/open.html http://pubs.opengroup.org/onlinepubs/000095399/functions/ope... [2] http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...
- wladimir 15y ago
  Yes. You are right. In general, you have to be really careful when passing user-provided input to syscalls. Embedded nulls are only one of the many pitfalls there (another one from the top of my head is unicode handling). Especially if you're writing a webserver.
- barrkel 15y ago
  It may be interesting to note that Windows syscalls (i.e. to the NT kernel rather than the Win32 layer wrappers like CreateFile) do not actually use null-terminated strings - they use UNICODE_STRING[1], which is a structure containing a 16-bit length, 16-bit buffer length, and pointer to a buffer of 2-byte characters. NtCreateFile[2] (and the kernel-side implementation of ZwCreateFile[3]) take a file name in the form of OBJECT_ATTRIBUTES, whose ObjectName field is of type PUNICODE_STRING. CreateFile is implemented in terms of NtCreateFile; CreateFile enforces Win32 semantics like case insensitivity that NtCreateFile does not; POSIX semantics can be implemented on top of NtCreateFile, but not easily with CreateFile. [1] http://msdn.microsoft.com/en-us/library/windows/hardware/ff564879%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/hardware/ff5... [2] http://msdn.microsoft.com/en-us/library/bb432380%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/bb432380%28v=vs.85%2... [3] http://msdn.microsoft.com/en-us/library/windows/hardware/ff566424%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/hardware/ff5...
  - deleted 15y ago
    [deleted]
- eklitzke 15y ago
  I'm not sure I follow you here. You can't have NULL characters in filenames on POSIX systems, so there's not an issue here (that I know of). What is the risk you're worried about?
  - kbolino 15y ago
    Sorry for the late reply. The risk only arises if the component of a system that accepts and validates user input does not use (or account for) null-terminated strings. That validator will see a different string than the syscall will; this is called null-character injection, and while it is difficult to craft effectively, it can lead to accessing resources that you thought you had protected by validating the string. You are quite correct that nulls are not legal characters in POSIX filenames; however, that is irrelevant. The nulls are only an issue in the processing; once they reach a syscall, the first one is treated as a terminator.

kbolino 15y ago

Something to bear in mind regarding non-standard string libraries: syscalls (like open[1] on POSIX or CreateFile[2] on Windows) use null-terminated strings, which means that you have to be careful about embedded nulls, no matter what library you use, when a string gets passed to a syscall somewhere in the chain. [1] http://pubs.opengroup.org/onlinepubs/000095399/functions/open.html http://pubs.opengroup.org/onlinepubs/000095399/functions/ope... [2] http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa36...

wladimir 15y ago
Yes. You are right. In general, you have to be really careful when passing user-provided input to syscalls. Embedded nulls are only one of the many pitfalls there (another one from the top of my head is unicode handling). Especially if you're writing a webserver.
barrkel 15y ago
It may be interesting to note that Windows syscalls (i.e. to the NT kernel rather than the Win32 layer wrappers like CreateFile) do not actually use null-terminated strings - they use UNICODE_STRING[1], which is a structure containing a 16-bit length, 16-bit buffer length, and pointer to a buffer of 2-byte characters. NtCreateFile[2] (and the kernel-side implementation of ZwCreateFile[3]) take a file name in the form of OBJECT_ATTRIBUTES, whose ObjectName field is of type PUNICODE_STRING. CreateFile is implemented in terms of NtCreateFile; CreateFile enforces Win32 semantics like case insensitivity that NtCreateFile does not; POSIX semantics can be implemented on top of NtCreateFile, but not easily with CreateFile. [1] http://msdn.microsoft.com/en-us/library/windows/hardware/ff564879%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/hardware/ff5... [2] http://msdn.microsoft.com/en-us/library/bb432380%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/bb432380%28v=vs.85%2... [3] http://msdn.microsoft.com/en-us/library/windows/hardware/ff566424%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/hardware/ff5...
- deleted 15y ago
  [deleted]
eklitzke 15y ago
I'm not sure I follow you here. You can't have NULL characters in filenames on POSIX systems, so there's not an issue here (that I know of). What is the risk you're worried about?
- kbolino 15y ago
  Sorry for the late reply. The risk only arises if the component of a system that accepts and validates user input does not use (or account for) null-terminated strings. That validator will see a different string than the syscall will; this is called null-character injection, and while it is difficult to craft effectively, it can lead to accessing resources that you thought you had protected by validating the string. You are quite correct that nulls are not legal characters in POSIX filenames; however, that is irrelevant. The nulls are only an issue in the processing; once they reach a syscall, the first one is treated as a terminator.