But what could a book last updated in the 1980s have to say about this subject? The phrase falls out of DR260 (Defect Report #260 in the ISO C standard) which wasn't even raised until this century.
Here's the mention of "provenance" from what WG14 (the committee for the C standard) wrote for DR260 back in 2001:
"the C Standard does not prohibit an implementation from tracking the provenance of the bit-pattern representing a value"
Vague right? And it's technically true, the C standard says nothing whatsoever about this subject. Of course it also doesn't have anything to say about which Pony is Best [Princess Celestia is Best Pony, don't @ me]
You might assume after DR260 the C standard was fixed. Presumably C11 and so C++ 11 and modern languages in this family all spell out how provenance works exactly right?
Nope.
The status quo is that the standard appears to say pointers are basically just addresses, but they clearly aren't in practice in your C or C++ compiler. If you raise bug reports about this, your compiler vendor will say it's provenance and, if you're persistent and they don't just stop answering you, eventually point to DR260, the unresolved defect from 2001.
There are folks trying to produce a consistent model which is somewhere in the ballpark of what programmers expect to work versus what compiler vendors actually deliver, so that both will be happy or, if not happy, at least both will agree on what the situation is. This model is some variation of what's called "Provenance Not Via Integers" but it must have exceptions because clearly sometimes provenance is transmitted via integers, and how that works must be explained too. WG14 did not take this work for C23, but it will become a Technical Specification in the C23 era. If compilers implement this TS, and if programmers prefer having at least the guarantees from the TS over a shrug emoji then perhaps some day it becomes part of the standard itself.
K&R mentions that you can't go around pointing to things of the wrong type (but C programmers do it anyway, and then doubtless you'll say K&R didn't warn them) and that you can't use pointer arithmetic to get at objects which are out of bounds (again, C programmers do it anyway).
The language is unsafe, and it's poorly designed in various ways by modern standards, but the OP didn't ask "What language should I learn?" they have apparently set their heart on learning C and so it's very strange to imagine the goal is to learn a good modern language which C isn't.
The question that I'm answering is "Best book to learn C in 2022?". K&R written as you say in the 1980s (the first edition in the 70s) is not that book, there is far better written material out there: One can get a solid grounding in C reading Seacord's books and John Regehr's blog without even needing to know who K and R are.
I'm guessing based on the comments to my posts that some people are upset due to K&R being their first introduction to C (or their first introduction to technical writing) which leads to emotional responses that miss the point.
So let me re-iterate that point. K&R is a terrible C book in 2022, and should not be recommended as an introduction to the language. It wraps C in a veneer of simplicity-hiding-untold-complexity which leads readers thinking that the language is much safer and much easier to deploy than reality dictates.
This has proven to be disastrous and something that we should point out and drive newcomers away from.
> I'm guessing based on the comments to my posts that some people are upset due to K&R being their first introduction to C (or their first introduction to technical writing) which leads to emotional responses that miss the point.
That's a shamelessly self-serving assumption.
When confronted with a claim/argument that is not favorable to your position, you have (at least) two options: one involves employing humility and intellectual honesty in an earnest attempt to resolve the conflict, and another involves inventing a convenient narrative in order to avoid the conflict. An example of the latter would be a stand-up comic who consistently bombs on stage and chooses to cope with it by telling themselves that the audiences are just too sensitive for the comic's edgy-but-otherwise-brilliant material. An example of the former would be for the comic to at least entertain the idea that their sets always bomb because the jokes are shit. Your response (which amounts to "u just mad") indicates that you seem to have taken this approach.
You have made a fact claim. You said that K&R "doesn't even attempt" to cover undefined behavior. That claim has been disputed. The next step for you to do is not to change the subject by questioning the motives and emotional maturity of those who have disputed the claim, but rather to substantiate it.
(For the sake of completeness: K&R was neither my first introduction to C nor my first introduction to technical writing—not that it matters.)
> One can get a solid grounding in C reading Seacord's books and John Regehr's blog without even needing to know who K and R are.
I'm not familiar with John Regehr - At least recently, Regehr's blog appears to be extremely low level (relative to C at least). Reading about the IR in LLVM or the ARM machine code which makes a spinlock go isn't a "solid grounding in C". It's fascinating - but it's not about C. Perhaps he used to write more about C?
Robert Seacord though, I just don't see it. I think you've recommended Seacord because you're thinking about what you'd need to write good software in C in 2022. But if we wanted to write good software in 2022 we shouldn't use C for that task in the first place. That's my point here. "Secure Coding in C" goes on the shelf next to "Agile Development using the Waterfall Model" and "Version Control using Visual SourceSafe". In each case these should be one paragraph inside, "Better not I think".
My assumption is that the OP is curious about the language, to the extent maybe they'll solve Advent of Code in it or something, not that they're about to write or maintain serious C software.
But what could a book last updated in the 1980s have to say about this subject? The phrase falls out of DR260 (Defect Report #260 in the ISO C standard) which wasn't even raised until this century.
Here's the mention of "provenance" from what WG14 (the committee for the C standard) wrote for DR260 back in 2001:
"the C Standard does not prohibit an implementation from tracking the provenance of the bit-pattern representing a value"
Vague right? And it's technically true, the C standard says nothing whatsoever about this subject. Of course it also doesn't have anything to say about which Pony is Best [Princess Celestia is Best Pony, don't @ me]
You might assume after DR260 the C standard was fixed. Presumably C11 and so C++ 11 and modern languages in this family all spell out how provenance works exactly right?
Nope.
The status quo is that the standard appears to say pointers are basically just addresses, but they clearly aren't in practice in your C or C++ compiler. If you raise bug reports about this, your compiler vendor will say it's provenance and, if you're persistent and they don't just stop answering you, eventually point to DR260, the unresolved defect from 2001.
There are folks trying to produce a consistent model which is somewhere in the ballpark of what programmers expect to work versus what compiler vendors actually deliver, so that both will be happy or, if not happy, at least both will agree on what the situation is. This model is some variation of what's called "Provenance Not Via Integers" but it must have exceptions because clearly sometimes provenance is transmitted via integers, and how that works must be explained too. WG14 did not take this work for C23, but it will become a Technical Specification in the C23 era. If compilers implement this TS, and if programmers prefer having at least the guarantees from the TS over a shrug emoji then perhaps some day it becomes part of the standard itself.
K&R mentions that you can't go around pointing to things of the wrong type (but C programmers do it anyway, and then doubtless you'll say K&R didn't warn them) and that you can't use pointer arithmetic to get at objects which are out of bounds (again, C programmers do it anyway).
The language is unsafe, and it's poorly designed in various ways by modern standards, but the OP didn't ask "What language should I learn?" they have apparently set their heart on learning C and so it's very strange to imagine the goal is to learn a good modern language which C isn't.