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

211–220 of 396 posts

Re: Modern C [pdf]

#211

Post by sidlls »

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.

C makes it trivial to implement poorly, though.

(Note: I'm playing devil's advocate here to some extent. My view is that safety is important, but lack of provable safety is not some terrible Demogorgon that we should hide in fear from. I think a lot of the concern over safety is valid, but in some contexts it's just overhyped.)

Re: Modern C [pdf]

#212

Post by [deleted] »

pwdisswordfish wrote: post #203
yoha wrote: post #199

Earlier quoted context omitted.

This is about weighing correction versus readability. In the "arrow operator" version, the readability is decreased; in the "proper" version, a type cast is required, and this can lead to bugs with values greater than 2^sizeof(ssize_t). Obviously, I just follow the convention when contributing to an existing project.

...values greater than 10?

[deleted]

Re: Modern C [pdf]

#213

Post by ape4 »

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.

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`.

Re: Modern C [pdf]

#214

Post by mixedCase »

jimmaswell wrote: post #84
mixedCase wrote: post #42

Earlier quoted context omitted.

>The omission of assert() makes Go a non-starter. A small syntactic sugar you can trivially implement yourself makes Go a non-starter? Go doesn't include assert in the language because you're supposed to do better than assert. Assert easily allows lazy programmers to let their programs freely crash without properly handling error conditions. Go prevents you from compiling with unused variables, and that combined with…

>Go prevents you from compiling with unused variables, and that combined with the Go documentation goes a long way towards teaching new Go programmers how they're expected to work. Things like this make me not want to use a language. Want to comment a=b; to a=3;//b temporarily? Too bad, either assign b to 3 or comment out b too, and if b was the only variable to make use of c, same for c, and so on. Same obnoxious no…

You can always use the black hole variable _

That mild inconvenience (which I almost never face while writing Go code after getting accustomed to the language and getting my editor to run goimports on save) has a big RoI in safety and program quality, which are much loftier goals than short term code-writing convenience.

Re: Modern C [pdf]

#215

Post by [deleted] »

yoha wrote: post #199
colanderman wrote: post #192

Earlier quoted context omitted.

Everyone should write your second example. The first does nothing but confuse. C has enough hazing rituals without garbage like "-->". The fewer tricks and patterns you use in C, the higher chance actual bugs have of being caught. Cutesy tricks like "-->" confuse human analysis and gain nothing.

This is about weighing correction versus readability. In the "arrow operator" version, the readability is decreased; in the "proper" version, a type cast is required, and this can lead to bugs with values greater than 2^sizeof(ssize_t). Obviously, I just follow the convention when contributing to an existing project.

[deleted]

Re: Modern C [pdf]

#216

Post by junke »

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.

Vulnerabilities like buffer overflow do not happen in languages with a string type. Humans are responsible if something bad happens, but without a safety net, the outcome is worse.

Re: Modern C [pdf]

#217

Post by pjmlp »

sacado2 wrote: post #190
pjmlp wrote: post #94

Earlier quoted context omitted.

Historical accident. It could have been written in any other language that compiled to native code, if we had more options available.

The Oberon operating system is as old as linux, yet I'm pretty sure you use the latter more often than the former.

Being an UNIX clone available for free instead of having to pay for expensive Solaris, Aix, HP-UX, SGI workstations, while BSD was busy fighting AT&T helped.

UNIX is the VHS of operating systems.

Re: Modern C [pdf]

#218

Post by loup-vaillant »

pawadu wrote: post #98
pjmlp wrote: post #94

Earlier quoted context omitted.

Historical accident. It could have been written in any other language that compiled to native code, if we had more options available.

Well, there are two types of people in this world 1. the type that do something 2. the type that claim they could do it better than the first group (this is by no means limited to programming, it is for example pretty common in politics) So please show me an OS written in Go or Rust or Ruby or Python or Java that people can actually use for day-to-day tasks.

There is such a thing as path dependence. C got ubiquitous because of reasons (UNIX?), and now we're stuck with it.

Now the historical accident theory is pretty obvious: it could have been an Algol, Fortran derivative instead of C, if only UNIX used that as a basis. C itself could have been designed differently, and if so would probably have different flaws and qualities.

Asking for a Rust/Go/Whatever OS is dishonest, because you know full well it will fail for reasons that have nothing to do with the underlying language's intrinsic qualities: even if that OS is great, nobody expect it to be so great we all have to switch away from Windows and Linux. Well, except maybe if we prove the correctness of the kernel, hence ensuring the absence of many vulnerabilities. Research is ongoing, I'd like to see where that goes.

Re: Modern C [pdf]

#219

Post by chongli »

jpfed wrote: post #163
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…

>enjoying the danger This is a hilariously bad attitude for any software that other people will use. When software crashes, people lose work and time. When software has vulnerabilities, bad guys take advantage of them and build stronger botnets. "The danger" isn't like wiping out when you're pulling a stunt; "the danger" is wasting the good guys' time and empowering bad guys. >There is a lot of great code written in…

This is a hilariously bad attitude for any software that other people will use. When software crashes, people lose work and time. When software has vulnerabilities, bad guys take advantage of them and build stronger botnets. "The danger" isn't like wiping out when you're pulling a stunt; "the danger" is wasting the good guys' time and empowering bad guys.

Computers aren't just tools, they're also toys. People use computers for entertainment in varied and sundry ways. What is so wrong with somebody wanting to enjoy hacking around in the low level guts of a system? As long as no lives or livelihoods are at stake, what's the problem?

Re: Modern C [pdf]

#220

Post by komali2 »

jackhack wrote: post #179

I wish I could like this book, but after reviewing the first chapter I can only imagine the confusion of students. I support very much the idea of breaking the book into levels, but it attempts to cover far too much, far too quickly and I don't believe this book would be useful for those who are not already familiar with the language. I've been writing C since the late 1980s, moved to mostly C++ by the mid 90s, C# in…

This has always been my problem with websites like codeacademy, and I started my entire career by learning through that website.

Take the Javascript course - a fantastic way to get introduced to the syntax of the language, and I highly recommend it for total noobies. But then you come out of it with no understanding whatsoever about what javascript is. If I asked someone who just finished the course to make an "app" that console.log'd to the console, they wouldn't understand where to start. They wouldn't know that JS is a language run in the browser, that they need an HTML file with a script tag or a node file that they can run in the terminal. They wouldn't know about DOM manipulation, etc.

This reminds me of the Java class I took in highschool - the teacher was going on about ints and floats and loops, and the only questioned I wanted answered, and never got an answer for, was "what does `public static void main` mean?" I think the fact that I never got an answer to questions like that are why it took me nearly 3 years into my career to figure out I should be a developer.

Post reply on HN