For the past 30 years or so, when seeing the word "(null)" (without the
quotes but with the parentheses) output in the middle of an otherwise
sensible output string, it has commonly been due to passing a null pointer
to printf or similar API. My understanding is that this started with BSD
Unix, maybe when someone decided that some abuses of null pointers were less
important than others so they made printf display (null) instead of
segfaulting, or maybe a coder of printf internals forgot that segfaulting
would be a good thing to do, at least during debugging stages.
Does a Windows XP API (maybe a native API) do the same thing? Or is it just
coincidence?
Does the boot-time version of the CHKDSK command pass a null pointer to an
API where a non-null pointer is required? Or is it just a coincidence?
Maybe the boot-time version of the CHKDSK command intentionally outputs the
word (null) to give geeks a scare but maybe it's mostly harmless?
It was really really comforting to see Windows XP boot after displaying the
following on a blue background:
Windows replaced bad clusters in file \pagefile.sys
of name (null).
Windows replaced bad clusters in file \WINDOWS\MEMORY.DMP
of name (null).
It was really really comforting to see Windows boot after that, and operate
without any apparent ill effects. It was really really comforting to see
Windows XP robustly survive some strongly suspicious evidence that low-level
internals are passing null pointers around where non-null pointers are
required. But maybe it was just a coincidence? Or by design?
Windows XP internals don't really pass null pointers around where non-null
pointers are required, right? They surely wouldn't pass such things to
printf, they surely wouldn't pass such things to memcpy, they surely
wouldn't write such things into memory descriptors in RAM or file
descriptors on disk or anything else like that, right? They've all been
verified, right?