Of course you can have NULL in a C string.
It is just that many (not all) standard C functions that accept
a string argument, interpret/use NULL for ending a string.
That is the convention used for many user defined functions
that accept string arguments or produce a string too.
But some standard C functions, e.g. strncpy, as well as many
user defined functions, instead take length or position
arguments (in one way or another). In such case NULL (represented
as a 0 value) in the string argument/result is just another
character. If you want to be able to process NULL as a
character in a text string, you must be careful to use
functions that don't interpret NULL as string termination.
A NULL (0) in a string can be used for all sorts of things,
e.g. new line (yes, new line), data missing, or even a
printable character, like COMMERCIAL AT (in the GSM 7-bit
encoding). And it may occur in input text files (or streams)
and it does NOT terminate a (text) file/stream.
But NULL (represented as 0) termination is handy when the
string is "known" to (or at least supposed to) contain
only "printable" characters in an ASCII or EBCDIC based
encoding. Like format strings, error messages, and so on.
But not for buffers containing (text) data obtained (e.g.)
from a file; unless you filter away, or internally "escape"
most control characters.
Many (text) *protocols*, quite apart from C, interpret some
characters specially, e.g. NULL (or all C0 control characters),
and those characters must be "escaped" somehow, if the protocol
allows for that. But that has nothing to do with C.
I've missed some of this thread, so I don't know why this
has become an issue. It's been like this for decades...
/kent k
