I did. It’s short, clear, well written and I found it an excellent introduction to C. I’d recommend it if you read it alongside some more modern supplements.

I can't speak for everyone, but I read K&R 4 years ago to supplement some of my classes in universtiy

Used it in college about 8 years ago. Can't say I'd do the same today, but back at that time it made some sense as college programming classes were teaching more than just practical programming knowledge.

Yes, it's a pretty good book. Not sure what the siblings are on about.

Yes, but that doesn't make it a good idea.

I have it on the bookshelf but haven't consulted it for many years.

Zed Shaw is sometimes a bit controversial but he wrote a "learn c the hard way" (or something similar) that aims to obsolete K&R.

That's what I used first. I did a lot more study, but I think that's actually the only book I used. What did it for me was trial-and-error and practice, but the most important part was getting the basics down so I could start reading through other people's good code.

K&R is a classic. A true exemplar of technical writing.

I am using it to study C. Can you tell me the reason why you wouldn't recommend it?

Despite being amazingly well written, the most recent edition of K&R was published in 1988. The current version of C is C18, released last year, so K&R is missing about 30 years of evolution. It's not a bad book, by any means, but it doesn't include important aspects about how C is used today.

K&R is a well written book, and is very pleasant to read. IMO, it is one of those books that everyone should read one day or the other.

The main thing to watch out about it these days is that K&R is a bit carefree about the numerous ways where you can shoot yourself in the foot using C. For example, K&R famously implements strcpy as `while(dst++ = dst++);`. These days, most people would say that code is excessively terse, and that you shouldn't be using strcpy in the first place (because it can potentially overflow the dst buffer).

You meant:

while ((dst++) = (src++))

I believe.

while ((dst++) = (src++));

Both of these replies are missing the asterisks to indicate pointer indirection. Probably HN is eating each asterisk, treating it as emphasis or something.

Also terse it may be, but this (assuming the missing asterisks are restored) is a good, idiomatic implementation of strcpy. Whether strcpy is good or evil is a separate discussion.

Because it's 30 years out of date. It's missing three revisions of the language. Teaches a lot of practices that lead to obtuse brittle code riddled with security holes.

Avoid.

can you be more specific about these practices?

What ufo said

> implements strcpy as `while(dst++ = dst++);

The book is full of stuff like that.

Doesn't strcpy always have that issue? The terseness is one issue, but the security problem is that it implements strcpy at all without warning.

You tend to get warnings to use the _s versions of some functions (strcpy_s in this case) these days.

I just tried (with gcc 9.2.1), and got no warning. As far as I know, these _s versions aren't that good, and often aren't available at all; see http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm which says among other things

"[...] none of the popular Open Source distribution such as BSD or Linux has chosen to make either available to their users. At least one (GNU C Library) has repeatedly rejected proposals for inclusion [...]"

"[...] As a result of the numerous deviations from the specification the Microsoft implementation cannot be considered conforming or portable."

"often aren't available at all"

It's in C11. Perhaps Red Hat use non-compliant compilers, or very, very old ones?

It's an optional part of C11, which means that even a fully compliant compiler does not have to implement them.

strcpy_s has no manual entry on Ubuntu, while "man strcpy" and "man strncpy" work as expected.

Why would that be?

I really enjoyed it, but it’s best supplemented with exposure to modern C syntax and an introduction to undefined behavior.