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