Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deconstructing K&R C Is Dead (2015)

c.learncodethehardway.org

Post reply on HN
Print view View original

111–120 of 190 posts

Re: Deconstructing K&R C Is Dead (2015)

#111

Post by ktRolster »

kinkdr wrote: post #81
tomjakubowski wrote: post #64

Earlier quoted context omitted.

Calling C from Rust is very convenient. All you have to do is declare the structs and function signatures and then it's like calling any other unsafe function.

IMHO it is OK if you are only going to call a few simple one, but for calling a few hundred complex ones (callbacks with variable argument list, etc..), it becomes a bit cumbersome. BTW I am not implying that is Rust's fault, actually I can't think a syntax that would make it less verbose, and I am a huge Rust fan.

actually I can't think a syntax that would make it less verbose.

something like C::function_from_c() is one option

Re: Deconstructing K&R C Is Dead (2015)

#112

Post by kinkdr »

Arnavion wrote: post #106
kinkdr wrote: post #101

Earlier quoted context omitted.

Why is it UB? Let's say head value is "10" and the memory at "10" is {..., next: "10"} After the first iteration we will have: Head: "10" Next: "10" Temp: "10" With "10" pointing to freed memory. But why do we care? We are not dereferencing it, are we? (I think I am missing something very obvious)

Because the standard says even comparing a dangling pointer is UB, which was haberman's point about the standard being non-intuitive.

Thanks. I wasn't aware of that. I stand corrected!!

Re: Deconstructing K&R C Is Dead (2015)

#113

Post by kinkdr »

jacquesgt wrote: post #107
kinkdr wrote: post #101

Earlier quoted context omitted.

Why is it UB? Let's say head value is "10" and the memory at "10" is {..., next: "10"} After the first iteration we will have: Head: "10" Next: "10" Temp: "10" With "10" pointing to freed memory. But why do we care? We are not dereferencing it, are we? (I think I am missing something very obvious)

I think you’re missing the fact that "There are a lot of rules you need to be aware of that are not naturally-occurring results of the fundamentals."

I was indeed. Thanks for the insight!

Re: Deconstructing K&R C Is Dead (2015)

#114

Post by __david__ »

Kristine1975 wrote: post #80
mjevans wrote: post #73

Earlier quoted context omitted.

I suspect this has a -lot- to do with performance. When C was designed, and even today, there are systems without pipelining, where it is expensive (in time) to de-reference a memory address and follow that pointer. I do not argue that the design you suggest would be safer, and even have advantages for slicing; but that's really not the kind of program that C was intended to service writing. Also, C is supposed to sc…

>I suspect this has a -lot- to do with performance. It's questionable whether people wanted that performance though, at least when it resulted in less security. About bounds checking in ALGOL 60: https://en.wikipedia.org/wiki/Bounds_checking A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the…

> It's questionable whether people wanted that performance though, at least when it resulted in less security.

There's no question about it, the "ANSI C Rationale" makes it very clear what they considered "the spirit of C"[1]:

> - Trust the programmer.

> - Don't prevent the programmer from doing what needs to be done.

> - Keep the language small and simple.

> - Provide only one way to do an operation.

> - Make it fast, even if it is not guaranteed to be portable.

> The last proverb needs a little explanation. The potential for efficient code generation is one of the most important strengths of C. To help ensure that no code explosion occurs for what appears to be a very simple operation, many operations are defined to be how the target machine's hardware does it rather than by a general abstract rule. An example of this willingness to live with what the machine does can be seen in the rules that govern the widening of char objects for use in expressions: whether the values of char objects widen to signed or unsigned quantities typically depends on which byte operation is more efficient on the target machine.

> One of the goals of the Committee was to avoid interfering with the ability of translators to generate compact, efficient code. In several cases the Committee has introduced features to improve the possible efficiency of the generated code; for instance, floating point operations may be performed in single-precision if both operands are float rather than double.

[1] http://www.lysator.liu.se/c/rat/title.html Quoted section is found here: http://www.lysator.liu.se/c/rat/a.html#1

Re: Deconstructing K&R C Is Dead (2015)

#115

Post by silent90 »

I'm sensing a huge incomprehension in a great amount of posts. The key is to know the purpouse of tools. C is a "close-to-the-metal" type language. You can control a low-level things, execution time, "number of hops" when writing data, etc. If you want a friendly language with "no segfaults, no memory leaks" then go higher level (which in many cases is a better choice, i.e. a GUI desktop application with no performance constraint). If you have a problems wrigint in C then you simply still can't C and using the wrong tool for the task.

"But C? C's dead. It's the language for old programmers who want to debate section A.6.2 paragraph 4 of the undefined behavior of pointers"

Someone has to build the low-level stuff. Dear boys in too-tight pants and a hippie mustache: your high-level things and gluten-free snacks does not grow on trees.

Re: Deconstructing K&R C Is Dead (2015)

#116

Post by regularfry »

ori_b wrote: post #38

The specific section of his 'Learn C the Hard Way' book that he's referring to was mostly, as I recall, complaining that the C string functions defined in K&R will fail when you don't pass them valid data, and therefore, they're fundamentally broken. Make of that what you will, but it seems to me that given all of the other ways that C can blow up due to programmer error, it seems reasonable to expect programmers to…

I'm with Zed on this one. Giving the programmer fewer things to have to remember, by design, is a de facto improvement. Forcing a human to repeatedly do a task which could have been designed out is evidence of a bad design.

Mind you, we're talking about the stdlib here. You can swap this stuff out. Some people do: djb is a fairly well-known example.

Re: Deconstructing K&R C Is Dead (2015)

#117

Post by dbaupp »

wahern wrote: post #100
Kristine1975 wrote: post #80

Earlier quoted context omitted.

>I suspect this has a -lot- to do with performance. It's questionable whether people wanted that performance though, at least when it resulted in less security. About bounds checking in ALGOL 60: https://en.wikipedia.org/wiki/Bounds_checking A consequence of this principle is that every occurrence of every subscript of every subscripted variable was on every occasion checked at run time against both the upper and the…

"The block structure of ALGOL 60 induced a stack allocation discipline. It had limited dynamic arrays, but no general heap allocation. The substantially redesigned ALGOL 68 had both heap and stack allocation. It also had something like the modern pointer type, and required garbage collection for the heap. The new language was complex and difficult to implement, and it was never as successful as its predecessor." -- h…

> There's a reason languages like Rust and Go rely heavily on static linking and stack allocation

This is untrue: Rust certainly does not do any optimisations linking statically by default, nor is there a difference between putting an array on the stack or on the heap. While it is true that code can benefit from whole-program optimisation, it isn't the default in either language, just like it isn't the default in C.

Re: Deconstructing K&R C Is Dead (2015)

#118

Post by blub »

pcwalton wrote: post #8

This is obviously a bitter rant, and devolves into uncomfortably ageist territory about halfway through. I do agree that we should be moving away from C and C++, though. It's pretty simple, really: C was a pretty good language in 1978. We didn't know a lot of things in 1978 that we do now in 2016. It now makes sense to revisit those decisions in light of nearly 40 years of practice. The so-called "PL Renaissance" has…

C can be replaced with a reasonable amount of effort with C++.

But C++ won't be easy to replace, and I'm not sure it needs to be, since rewrites are highly risky, time consuming and disruptive. With some luck and depending on how the language evolves we might be moving from C++ to a safer C++.

Re: Deconstructing K&R C Is Dead (2015)

#119

Post by blub »

pcwalton wrote: post #14
jimbokun wrote: post #11

Earlier quoted context omitted.

It's remarkable, though, that it's taken 40 years to make much head way in replacing C. There's still a lot of C code out there, and a lot of new C code still being written.

> It's remarkable, though, that it's taken 40 years to make much head way in replacing C. I don't agree: it's been a long process, but the trend is unmistakable. It's hard to remember now, but in the early '90s C and C++ were completely dominant. Nowadays they're much more specialized: you're as likely to build your company on Java or even Python/Ruby as you are to build it on C++. People talk about how it's hard to…

That's quite normal, because the market today is much larger and diverse. e.g: It doesn't make any sense to build web apps in C or C++ and this type of software is very spread nowadays but was virtually non-existing back then.

The interesting question is what will mobile devices, the IoT and embedded devices in general be programmed in? C and C++ are popular choices today, so the trend is not really "unmistakable".

Re: Deconstructing K&R C Is Dead (2015)

#120

Post by JokoX »

haberman wrote: post #62
kinkdr wrote: post #54

Earlier quoted context omitted.

> Low level languages are tough I disagree. Low level languages, especially C, are the easiest to master. K&R book is the only book you need to read to know everything about C. All you need after you understand the fundamentals is a bit of discipline. C++ on the other hand is extremely difficult to master. Just have a look at the rules for Rvalue references and you will see what I mean. It may be easier for a complet…

> K&R book is the only book you need to read to know everything about C. All you need after you understand the fundamentals is a bit of discipline. I am a huge C fan but this is not true at all. C has tons of pitfalls, especially with modern UB-aggressive optimizing compilers. There are a lot of rules you need to be aware of that are not naturally-occurring results of the fundamentals.

For someone who wants to learn C from the ground up, do you have some kind of learning path or books you'd recommend?
Post reply on HN