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

Modern C [pdf]

icube-icps.unistra.fr

Post reply on HN
Print view View original

221–230 of 396 posts

Re: Modern C [pdf]

#221

Post by pcwalton »

chrisd1100 wrote: post #202
pcwalton wrote: post #164

Earlier quoted context omitted.

> So in this sense, the quality of the C you write is really a reflection of you as a C programmer, not the shortcomings of the language. Can't you substitute "C" with just about anything in this sentence? It's all well and good to talk about how "beautiful" a language is, but when people are literally endangered because of totally preventable security vulnerabilities that don't happen in programs written in other la…

But don't the security vulnerabilities come from poorly implemented code? These vulnerabilities are not inherent to C.

In what commonly used language other than C and C derivatives do you regularly see use-after-free leading to remote code execution?

Re: Modern C [pdf]

#222

Post by drivingmenuts »

pksadiq wrote: post #129

I would recommend that anyone who hires a programmer should test his/her knowledge in C (especially in areas like code that produces undefined or unspecified results), even if the candidate is never going to code in C, ever. If he/she knows these concepts well, that means he/she have invested much time, and probably know other things well enough (or can learn them easily).

Hire a Javascript programmer and lemme know how that works out for you.

There's no point in testing for C knowledge if they're never, ever going to use it. Sure, they may know some C, but they're not going to have more than a surface, I-recognize-it-when-I-see-it understanding of it.

Re: Modern C [pdf]

#223

Post by pjmlp »

vram22 wrote: post #197
wiz21c wrote: post #134

Earlier quoted context omitted.

Turbo Pascal even allowed to mix in assembler right in your source code. That was super awesome at that time. No need to write separate assembly code, no need to link ! (not to say that Turbo Pascal was the only one to do that, just fond memories...)

Interesting. Though I used Turbo Pascal quite a lot earlier, I either don't remember that feature (being able to mix in assembly) or may have known of it then but forgotten it later. Getting a vague recollection - was it something like a function call of sorts (syntax-wise)? Start with a $something, then open parens, then some assembly statements, then close parens)? If that was the way it was done in TP, the BBC mic…

In TP you could use inline Assembly in several ways.

It could be just a block, a complete procedure/function with or without prolog.

Also it was quite comfortable to write, just as a plain macro Assembler with Intel syntax, not those asm functions with strange syntax used in gcc/clang.

Re: Modern C [pdf]

#225

Post by yekim »

chrisd1100 wrote: post #114

I'm really surprised by the "hate" for C that is appearing in these comments. What ever happened to actually enjoying the danger of getting low level? Is assembly also useless because it isn't readable? There is a lot of great code written in C, and a lot of crappy code written in C. Because C doesn't protect you from yourself, it exacerbates any design flaws your code may have, and makes logical errors ever more ins…

Hear, hear!

Unfortunately, C does get a lot of hate on HN. I suspect it has to do with this site's demographics. Many (not all) of the HN clan seem to be oriented towards / mostly familiar with web based technologies. I suspect that for many who have tried, going from a web dev environment to a C oriented dev environment feels like a robust shock to the system.

I'd also be willing to bet that there's an age bias at play here; C has been around, like, forever. It is certainly not the new hotness. Most (not all) people that I know who enjoy it and are proficient at it, are 40 or older. Much of the web based dev crowd that hang around HN seem to be in their 20s, and as it is a time honored tradition to poo-poo the ideas / methods / tech of the older generation(s), it's not surprising that C doesn't get a lot of love.

Yes, I realize I'm painting with broad strokes here. It'd be interesting to see a survey or three that correlates age ranges and tech used on a day-to-day basis to see if these assumptions or legit. (Anyone got any survey data up their sleeve they'd be willing to share?)

Me personally - I love it all. C, C++, Java, Python, Javascript, Rust, Haskell, Scheme, etc. Making computers do things for you, and for other people, by writing detailed instructions is quite possibly one of the funnest things in the world. Double bonus for getting paid to do it!

Re: Modern C [pdf]

#226

Post by 72deluxe »

ape4 wrote: post #213
thegeomaster wrote: post #143

Earlier quoted context omitted.

I've found goto to be a good way of dealing with exceptions in low-level C. For example: void* foo() { int handle = get_some_handle(); if (handle I've seen this pattern frequently in the Linux source code. I think this is an example of a case where usage of goto improves readability and reduces errors.

This looks fine to me. I wonder if C/C++ could be improved by introducing a new keyword `bail` which is the same as `goto` but is only allowed to jump to the bottom of the function. That way, codebases can outlaw `goto` but keep `bail`.

Are you looking for "return"?

With C++ you can ensure that you have your destructors do the tidy up, e.g. a messy example

struct cleaner { cleaner(string *toCleanup) : m_x(toCleanup) { } ~cleaner() { delete m_x; m_x = nullptr; } };

Re: Modern C [pdf]

#227

Post by bluetomcat »

pcwalton wrote: post #166
bluetomcat wrote: post #138

Earlier quoted context omitted.

Undefined behaviour actually isn't the monster that most C language lawyers want you to believe it is. With tools like valgrind, address sanitizers and modern debugging toolchains, most of these issues can be caught. Compilers are also mature enough to issue warnings about the use of uninitialized variables, missing return statements or mismatched printf specifiers. Heck, Clang maybe has more than 250 -W options.

In theory, a good fraction of these can be caught. In practice, these issues keep coming up in production again and again and again.

Knowing your tools and compiler switches is key. The reward is that the final production code can be very lean and performant, without any runtime penalties to provide safety.

Most people who complain about the dangers of C probably have used it in an unprofessional setting without any additional tooling. It's a bit like saying that all RWD cars are dangerous just because you've once driven a '92 BMW, disregarding any technological advancements since.

Re: Modern C [pdf]

#228

Post by [deleted] »

CmdrSprinkles wrote: post #76
buserror wrote: post #56

Earlier quoted context omitted.

Yeah, again and again. it's like blaming a hammer for the potential of breaking your finger when you use it, and proposing the use of a spoon, instead.

While I am all about C/C++ (even if I hate it), it makes sense HN is probably something like 99% web and app developers (I would argue that all are the former, but my definition may be a bit old). In those cases, you actively don't want to ever use C and anyone who does is kind of an idiot. It is the logic by which "systems project" means "script to run on a server" for a lot of people around here. And that is fine.…

[deleted]

Re: Modern C [pdf]

#229

Post by dang »

CmdrSprinkles wrote: post #76
buserror wrote: post #56

Earlier quoted context omitted.

Yeah, again and again. it's like blaming a hammer for the potential of breaking your finger when you use it, and proposing the use of a spoon, instead.

While I am all about C/C++ (even if I hate it), it makes sense HN is probably something like 99% web and app developers (I would argue that all are the former, but my definition may be a bit old). In those cases, you actively don't want to ever use C and anyone who does is kind of an idiot. It is the logic by which "systems project" means "script to run on a server" for a lot of people around here. And that is fine.…

> HN is probably something like 99% web and app developers

Most generalizations about HN are merely projection based on sample bias, so please don't post such generalizations unless you have representative data.

We're thinking about adding that sentence to the site guidelines, because spurious general claims about HN are a cliché here.

Re: Modern C [pdf]

#230

Post by yekim »

thegeomaster wrote: post #143
ape4 wrote: post #135

Goto is considered useful by the book: The use of goto and similar jumps in programming languages has been subject to intensive debate, starting from an article by Dijkstra [1968]. Still today you will find people that seriously object code as it is given here, but let us try to be pragmatic about that: code with or without goto can be ugly and hard to follow.

I've found goto to be a good way of dealing with exceptions in low-level C. For example: void* foo() { int handle = get_some_handle(); if (handle I've seen this pattern frequently in the Linux source code. I think this is an example of a case where usage of goto improves readability and reduces errors.

Yes - a thousand times yes!

The goto has gotten a bad rap over the years because of Dijkstra's paper. And that paper has unduly influenced a lot of incorrect thinking. There are valid use cases for goto, and this is certainly one of them.

I use it all the time like the example above. Particularly because it makes my life so much easier when developing and debugging embedded C code across various tool chains, some of which have less functionality than others.

[edit - correct typo on Ed's name]

Post reply on HN