7 ms·

King is good, also Seacord’s books: Effective C and Secure Coding .. Just ignore suggestions (parroting really) for K&R. It’s probably the worst introduction t

King is good, also Seacord’s books: Effective C and Secure Coding .. Just ignore suggestions (parroting really) for K&R. It’s probably the worst introduction to C when it comes to good habits, undefined behavior and writing secure code, since it doesn’t even attempt to cover any of these but presents a total facade regarding what programming in C is like. K&R has created generations of people who call themselves C programmers but are essentially clueless when it comes to deep understanding of the language. Anyone that recommends K&R today is someone you want to avoid taking any advice on programming from.

mburee 4y ago
Well when K&R C was released the compiler landscape did look very different. I'm sure back then you could get away with a lot more UB than nowadays, where LLVM and GCC will use every millimetre of leeway you give them to break your programs.
frou_dh 4y ago
The memetic nature of the term "K&R" also seems to have resulted in a lot of people who think Kernighan created Unix, and don't know who Ken Thompson is.
flohofwoe 4y ago
K&R was a very interesting read for me, but not actually for the description of the C language, but because it describes why certain features in C look the way they do, and because it is also surprisingly and refreshingly critical towards the language (e.g. it basically admits that the function pointer syntax was a mistake). It also corrected my oversimplified view that C is a simple and small language simply because it is an old language, but it was already a simple and small language compared to other languages in the late 60's and early 70's 'programming language zoo'. All the code examples are deeply rooted in the 80's programmer mindset though, and are not very relevant for "modern C".
cxr 4y ago
It's hard to take someone seriously or believe that they've even read the material when they say stuff like this. K&R (2nd ed.) is constantly calling out undefined behavior, etc. and gives you information you need to start out on a path to be a real stickler about the language. I spent time on my own learning C from K&R since the CS program at my school didn't expose anyone to C (or C++) during the first year. Later, in e.g. the computer architecture course or the data structures course when C was being used liberally (and sloppily), and as I was running across lots of C in the wild, I was continually frustrated by the frequency I saw people relying on common-but-undefined behavior that's explicitly identified as unsafe/unreliable in K&R. Here's my advice to the original poster: If you come across unsubstantiated comments telling you to ignore K&R for all the bad things it contains, then ignore those. Or you can ask for evidence of the bad things they say about it. It's become a meme in the last few years to write meatless swipes about how bad K&R is, but in all the times I've asked for evidence of the things it's purportedly rife with, no one has ever produced anything. The most egregious thing I know of is that it uses `gets` and `puts` in some places—while taking extra effort to tell you it's wrong to use them. This is arguably exactly how do-not-do-this wisdom should be imparted. There is one criticism that holds true about K&R, if you're being generous (to the naysayers, that is), which is that it really does just teach you C the programming language (with some extra stuff about the UNIX system interface at the end). It's not a general software engineering book. You don't learn about build tools or how to structure large, maintainable programs. It exposes you to the fact that C has various nooks and crannies, and it teaches you them, and that's all it really tries to be.
- armitron 4y ago
  > which is that it really does just teach you C the programming language A gross misrepresentation that, taken at face value, can only lead to a perpetuation of disasters committed by the sort of C programmers that K&R has produced in droves. Just because there are a few mentions of undefined behavior in K&R, doesn't mean the concept is addressed or even identified as an issue. There is not a single mention of the "C abstract machine" (what is that, the K&R C programmer wonders), pointer provenance, aliasing, or pretty much any aspect of the language that has emerged in the last 20 years as of supreme importance to correctness and security. As someone else wrote in this thread, the entire book is hopelessly obsolete and should be retired to the annals -if not the garbage bin- of history.
  - tialaramex 4y ago
    > pointer provenance 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.
GeneT45 4y ago
Agreed. It's also worth pointing out that Effective C is the most current in terms of being up to date with present-day C standards. K&R is so obsolete it's now wrong about some things. It's a pretty good read sometime down the road - when you can recognize its shortcomings - but it's not a book from which to start learning C.
rramadass 4y ago
The above is a utterly clueless post and is best ignored. To the OP: K&R Ansi C is one of the best book to learn "Fluent C". The code is terse, no-frills and to-the-point. It is not a "Software Engineering" book so you have look elsewhere for that. Also without an understanding of the language, its runtime services and system interfaces (eg. ABI) it is pointless to look at Security/UB and hence don't bother about it in the beginning; You can get to it later. In summary, read K&R C along with any other books that you like.

mburee 4y ago

Well when K&R C was released the compiler landscape did look very different. I'm sure back then you could get away with a lot more UB than nowadays, where LLVM and GCC will use every millimetre of leeway you give them to break your programs.

frou_dh 4y ago

The memetic nature of the term "K&R" also seems to have resulted in a lot of people who think Kernighan created Unix, and don't know who Ken Thompson is.

flohofwoe 4y ago

K&R was a very interesting read for me, but not actually for the description of the C language, but because it describes why certain features in C look the way they do, and because it is also surprisingly and refreshingly critical towards the language (e.g. it basically admits that the function pointer syntax was a mistake). It also corrected my oversimplified view that C is a simple and small language simply because it is an old language, but it was already a simple and small language compared to other languages in the late 60's and early 70's 'programming language zoo'. All the code examples are deeply rooted in the 80's programmer mindset though, and are not very relevant for "modern C".

cxr 4y ago

It's hard to take someone seriously or believe that they've even read the material when they say stuff like this. K&R (2nd ed.) is constantly calling out undefined behavior, etc. and gives you information you need to start out on a path to be a real stickler about the language. I spent time on my own learning C from K&R since the CS program at my school didn't expose anyone to C (or C++) during the first year. Later, in e.g. the computer architecture course or the data structures course when C was being used liberally (and sloppily), and as I was running across lots of C in the wild, I was continually frustrated by the frequency I saw people relying on common-but-undefined behavior that's explicitly identified as unsafe/unreliable in K&R. Here's my advice to the original poster: If you come across unsubstantiated comments telling you to ignore K&R for all the bad things it contains, then ignore those. Or you can ask for evidence of the bad things they say about it. It's become a meme in the last few years to write meatless swipes about how bad K&R is, but in all the times I've asked for evidence of the things it's purportedly rife with, no one has ever produced anything. The most egregious thing I know of is that it uses `gets` and `puts` in some places—while taking extra effort to tell you it's wrong to use them. This is arguably exactly how do-not-do-this wisdom should be imparted. There is one criticism that holds true about K&R, if you're being generous (to the naysayers, that is), which is that it really does just teach you C the programming language (with some extra stuff about the UNIX system interface at the end). It's not a general software engineering book. You don't learn about build tools or how to structure large, maintainable programs. It exposes you to the fact that C has various nooks and crannies, and it teaches you them, and that's all it really tries to be.

armitron 4y ago
> which is that it really does just teach you C the programming language A gross misrepresentation that, taken at face value, can only lead to a perpetuation of disasters committed by the sort of C programmers that K&R has produced in droves. Just because there are a few mentions of undefined behavior in K&R, doesn't mean the concept is addressed or even identified as an issue. There is not a single mention of the "C abstract machine" (what is that, the K&R C programmer wonders), pointer provenance, aliasing, or pretty much any aspect of the language that has emerged in the last 20 years as of supreme importance to correctness and security. As someone else wrote in this thread, the entire book is hopelessly obsolete and should be retired to the annals -if not the garbage bin- of history.
- tialaramex 4y ago
  > pointer provenance 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.

GeneT45 4y ago

Agreed. It's also worth pointing out that Effective C is the most current in terms of being up to date with present-day C standards. K&R is so obsolete it's now wrong about some things. It's a pretty good read sometime down the road - when you can recognize its shortcomings - but it's not a book from which to start learning C.

rramadass 4y ago

The above is a utterly clueless post and is best ignored. To the OP: K&R Ansi C is one of the best book to learn "Fluent C". The code is terse, no-frills and to-the-point. It is not a "Software Engineering" book so you have look elsewhere for that. Also without an understanding of the language, its runtime services and system interfaces (eg. ABI) it is pointless to look at Security/UB and hence don't bother about it in the beginning; You can get to it later. In summary, read K&R C along with any other books that you like.