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

311–320 of 396 posts

Re: Modern C [pdf]

#311

Post by ArkyBeagle »

sqeaky wrote: post #270
clarry wrote: post #265

Earlier quoted context omitted.

I don't think anyone can demonstrate that it is virtually impossible to write 100% safe C code. Sure, you can always find people who don't know how to write a proper safety check. That doesn't mean nobody knows. You can always find people who ignore or don't know about best practices, but that doesn't mean everyone's like them. And you can find people who write goto fail; and ignore the warnings about unreachable cod…

I think that you have the formulation backwards. You claim that people can just write better, and should attain perfection. > I don't think anyone can demonstrate that it is virtually impossible to write 100% safe C code. I think most people come at the other way. Most people are aware that they are fallible and wants tools to help with that. Most people strive for perfection and none will ever actually attain it. >…

So I see this argument as "should the tools catch these things?". I suppose that would make some people feel better. But the fact is, when you're in the seat, it's up to you to make sure you Do No Harm.

But please be aware - generalizing all failures and integrating them into the tool suite is a pretty daunting task. Perhaps the economics of it make sense. But if you're stuck writing 'C', especially on legacy code bases with legacy tools, you're stuck, and there's only the one thing to do...

Re: Modern C [pdf]

#312

Post by ArkyBeagle »

rileymat2 wrote: post #126
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…

There is also the issue of undefined and implementation defined behavior. When developing on one platform for an extended period of time, it is human nature to forget which features are implementation defined as you use them day after day and then have unexpected errors/flaws when porting.

Porting is it's own thing - you must seperate implementation dependent things and ... "business rules" fairly strictly if you are to keep it portable. I'd also strongly suggest a really comprehensive test suite that beats the snot out of the implementation dependent portions.

Somebody mentioned "scripting languages" - use the ability of scripting languages to construct combinators to write your tests. They migth even emit 'C' code.

Re: Modern C [pdf]

#313

Post by ArkyBeagle »

junke wrote: post #157
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.

Are you sure you aren't mixing causes and consequences? I'd say that this is actually because undefined behaviour is hard (didn't say impossible) to get right at the human level that tools were, and still are, being developed.

UB and IB ( implementation-defined ) have not been a problem for me for a couple decades now. No advocacy here - I started using C because it was about all there was - but it's just a learning curve.

There was no direct cost to me because I was getting paid to learn this stuff on the job.

Re: Modern C [pdf]

#314

Post by ArkyBeagle »

sidlls wrote: post #242
chongli wrote: post #219

Earlier quoted context omitted.

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 com…

What's amusing to me is the amount of terribly unsafe code (that isn't C) that powers rockets, moon landers, and a variety of other safety-critical systems and yet isn't the subject of such persistent and severe criticisms. There's a reason C and C++ are targets. My (obviously controversial) opinion is it has at least as much to do with ego as a desire for safety.

We have a winner. Kill your ego. It's the only way.

Re: Modern C [pdf]

#315

Post by tormeh »

____nope wrote: post #297
ticviking wrote: post #279

Earlier quoted context omitted.

This is an idea that many people resist. I think they mistakenly believe that programming languages are genuinely difficult to learn, and students must start on one that is marketable.

It's hard to teach an introduction to programming without teaching a particular language. If you have to pick a particular language, it makes sense to choose something the student is likely to use in the future. This is not hard to understand.

I don't really approve of this view. CS students are going to be programming in current-gen languages like Java, Python, C/C++ and JS in industry anyway (C is perhaps last-gen...). I think academia should lie a couple steps ahead and introduce students to stuff that will help them advance the industry. Next-gen and maybe experimental/academic languages and tools. Teaching students current industry languages/tools is good for the individual student but bad for the industry as a whole because it causes stagnation. Universities are big enough that they ought to be able to rise above this tragedy of the commons and do something for the greater good rather than think narrowly of the individual student.

Re: Modern C [pdf]

#316

Post by [deleted] »

dvirsky wrote: post #274
PDoyle wrote: post #44

Earlier quoted context omitted.

> Assert easily allows lazy programmers to let their programs freely crash without properly handling error conditions. This is what he meant by misuse. Properly-used assertions are meant to document and check conditions that were thought to be impossible by the developer. Not just unlikely, or illegal, but impossible. If a condition is possible, and you check it with assert, that's a bug.

I came to detest assert when I was working on a project with another guy, who used it generously, as a substitute for assertions in (non existing) unit tests. Nothing would annoy me more than working on my code, running it, and having all sorts of weird assertions pop up all over the place from this guy's code.

[deleted]

Re: Modern C [pdf]

#317

Post by ArkyBeagle »

junke wrote: post #216
chrisd1100 wrote: post #202

Earlier quoted context omitted.

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.

C has a perfectly useable (null-terminated) string type, and there is no good reason to ever have a buffer overrun in C.

I understand that this is... obscure for some reason and I'm not saying it never happens, but let's be realistic....

Re: Modern C [pdf]

#318

Post by ArkyBeagle »

wiz21c wrote: post #134
pjmlp wrote: post #133

Earlier quoted context omitted.

C was not the only way of doing it. Many of us were enjoying the danger of getting low level with Think/Quick/Turbo Pascal and Modula-2.

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

I don't recall specifically about MSC but Turbo C had the same....

We considered having all the assembler in separate files better practice...

Re: Modern C [pdf]

#319

Post by __d »

sndean wrote: post #201

Pardon my noobness, but if I learned and became proficient in C and knew nothing else, would I have a marketable skill? Is it possible for C to be a standalone skill, where ones job could be 100% programming in C, or do you need a lot of auxiliary knowledge outside of that?

Probably not.

C doesn't exist in a vacuum: it has to run on something. And the standard library doesn't get you very far.

You'd need to know at least one OS API as well: POSIX is probably best, maybe Win32, an embedded OS/executive might work also, or perhaps even a bare-metal CPU or two.

C + POSIX covers a lot of the Open Source world, and increasingly more of the embedded market. C + VxWorks is possibly the next best combo.

Re: Modern C [pdf]

#320

Post by crpatino »

Koshkin wrote: post #120
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…

People have strong feelings about C because C is far from being perfect by modern standards and yet it continues to be the single most important programming language of our time. There is nothing wrong or surprising with people being frustrated about this fact. I only wish that there was less irrational hate on this forum in this regard.

Well, the haters could always reimplement the whole infrastructure in their language of choice, wouldn't they?

It's been done at least once before for ideological reasons (and in C none-the-less) by the FSF. It should be even easier to give it a go in modern languages. I bet you can even get funding if you can write a compelling case that the wheel is actually broken!!!

Post reply on HN