Correct use of 'nul' 'null' and capitalization in the book

[alexandermerritt]

r? @steveklabnik

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @steveklabnik (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[steveklabnik]

Hey @alexandermerritt ! Sorry this review took a while.

So, we don't have any standard here, but IIRC, @retep998 specifically used NUL in those contexts because they were meaningful. Maybe they can chime in and confirm?

[retep998]

I use NUL when referring to the DOS device equivalent to /dev/null. NULL is what I use when referring specifically to the C definition. I typically just use null when talking about null pointers.

[retep998]

Why is it back ticked here? It's definitely not an identifier that Rust uses, so it seems wrong.

[steveklabnik]

Yeah, I would also think that this shouldn't be backticked, even though it was originally

[retep998]

The way MSDN does it is they refer to strings as being null terminated, while the ascii character itself is referred to as NUL yet they call it the null character.

[alexandermerritt]

@steveklabnik @retep998 Thanks for the feedback!

The use of these terms seems to not be fully consistent and I believe leads to confusion. For example, Wikipedia uses "Null-terminated string" to mean C string terminated with '\0' as does your reference in MSDN, but MSDN also calls the ending byte in a C string as the "null character". I know them as NUL being the single-byte character marking the end of a C string '\0' (as worded in POSIX), and NULL being the value of a pointer which is invalid or uninitialized (in POSIX but also referred to as the "null pointer").

I do not agree in written text that both a string can be "null-terminated" when there exists also a "null pointer", as a "null string" then means what? (A "C string" ends with NUL but can have value NULL which means it then does not exist.)

My philosophy is, when referring to the values, NUL as '\0' and NULL as (void*)0, they are capitalized. For example, stating "compare to null" is misleading; does it mean compare a single byte, or a word size? Thus strings are terminated with NUL or "NUL-terminated" and invalid pointers are NULL or are "null pointers".

Perhaps most of this is just a writing style preference? My motivation is that many people are still confused as to the difference between NUL, NULL (wrt. their size, and their context), and "null", so I wanted to help standardize their use, but please feel free to choose what you feel is appropriate.

[steveklabnik]

Whew, even in a language without null, null is a problem 😓

My philosophy is,

I like it.

[steveklabnik]

@bors: r+ roillup

[bors]

📌 Commit 161ba12 has been approved by steveklabnik

[bors]

⌛ Testing commit 161ba12 with merge 731d375...

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-cargotest, auto-linux-64-cross-freebsd, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-opt-mir, auto-linux-64-opt-rustbuild, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-opt, auto-mac-64-opt-rustbuild, auto-mac-cross-ios-opt, auto-win-gnu-32-opt, auto-win-gnu-32-opt-rustbuild, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-cargotest, auto-win-msvc-64-opt, auto-win-msvc-64-opt-mir, auto-win-msvc-64-opt-rustbuild
Approved by: steveklabnik
Pushing 731d375 to master...

[alilleybrinker]

A small comment: would it be useful to start some Rust project language guide to document these sorts of practices? That way there's something to point new contributors toward when writing docs, and obvious against which existing documentation can be evaluated.