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

301–310 of 396 posts

Re: Modern C [pdf]

#301

Post by uryga »

loup-vaillant wrote: post #141
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).

Let's not confuse low level understanding with the fine points of the C virtual machine, which drifts from whatever platform you are working on by the year. What you really want is an understanding of how whatever code the candidate may write will map to the underlying hardware. Test for that.

do you have any pointers for reading about "the C virtual machine"? i'd love an accessible explanation of how the model of the hardware predented by C differs from actual modern chips, but those keywords make it hard to google for.

Re: Modern C [pdf]

#302

Post by dbaupp »

the_why_of_y wrote: post #263
SQLite wrote: post #36

Earlier quoted context omitted.

Go has chosen to omit assert(), because assert() is frequently misused they say. Antibiotics are also frequently misused, but that is not a good reason to prohibit them. The omission of assert() makes Go a non-starter. Rust seems more promising, but it is still not to the point where I am interested in rewriting SQLite in Rust, though I may revisit this decision in future years. Some current reasons to continue to pr…

> (5) Rust has "immutable variables". Seriously? How can an object be both variable and immutable? Variables have been called variables since the dawn of time, i.e., the lambda calculus, which doesn't even have assignment. The name derives from the idea that for every invocation of a function, a variable in its definition may be bound to a different value, hence it "varies" at runtime.

Furthermore, it's terminology from mathematics, where, just like the lambda calculus, mutation isn't a thing: https://en.wikipedia.org/wiki/Variable_(mathematics)

Re: Modern C [pdf]

#303

Post by accatyyc »

wangchow wrote: post #177
aleksei wrote: post #52

Another day for the HN crowd to express their distaste for C :)

And.. While they express such distaste the haters probably serve their web apps via NGINX.

... and put all their keys and values in Redis. And use curl for testing their revolutionary REST-API!

Re: Modern C [pdf]

#304

Post by uabstraction »

dagw wrote: post #49
Waterluvian wrote: post #15

I've had no luck learning a language on its own. But I've had a lot of luck learning languages as part of something bigger. Like C# via. Unity, Swift via. 2D game dev in XCode. Any suggestions on what I should apply C to as a way to learn it?

Arduino and other micro controllers. First of all it's really fun (YMMV). There is something about writing code that makes things happen in the physical world which is satisfying in ways that writing code that just affects bits on a computer isn't. Secondly it's one of the realms where C is still genuinely important. When you are working on problems where a few hundred bytes this way or that is difference between suc…

If you want to push this to the extreme, check out the MSP430 Launchpad and fiddle around with avr-gcc. Pick up a Bluetooth serial module (can be had on breakout board for ≈$40) and remote control something from any Android phone. Lots of fun to be had.

Just be aware, microcontroller C programming is pretty far out compared to regular systems programming. Lots of tasks involve writing bits to seemingly random memory-mapped registers to change the state of the controller... and forget about including your favorite libraries. You're lucky if the standard library fits on the chip. Its very similar to OS kernel development in that regard.

Re: Modern C [pdf]

#305

Post by Koshkin »

mpweiher wrote: post #281
Koshkin wrote: post #125

Earlier quoted context omitted.

"Prehistoric" or not, the classical C as created by Kernighan and Ritchie is actually a perfect example of a sensibly minimalist design. Subsequent changes made to the language have spoiled the characteristic elegance of that design.

Well, function prototypes in the first ANSI standard were a fine addition, if you ask me. After that...

This is where it all started. In general, I would agree with you, but the immediate loss of the original elegance and simplicity of the design is obvious. (Also, I believe it was a deliberate design decision to only require that the return type be specified - if it is not 'int' - in a declaration of a function. Besides having resulted in easy-to-understand semantics and an uncluttered syntax, this opened a direct way of dealing with an unknown number and/or types of the arguments without needing any additional syntactical "niceties".)

Re: Modern C [pdf]

#306

Post by sidlls »

baka wrote: post #285
sidlls wrote: post #242

Earlier quoted context omitted.

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.

As far as I know most space software these days, and embedded in general, is in (at least a sub/superset of) C.

Yes, but it wasn't always, and still isn't always.

Although your point is very good in that it weakens (further) the "safety is everything" argument. In my opinion. There is so much mission critical software today that is written in C and C++. That's one reason why "safety, safety, safety!" just isn't as persuasive to me as it perhaps is to others.

Re: Modern C [pdf]

#307

Post by bonzini »

jjesus wrote: post #61
pawadu wrote: post #48

Earlier quoted context omitted.

> We bind type modifiers and qualifiers to the left. Good idea in theory but your example shows how bad it behaves in practice.

Usually declare variables one per line, so, type is still clear when: char* var1; char var2;

And then leave the poor beginner wondering why it's

char var1[10];

and not

char[10] var1;

The rule is simple once you understand it, variables are declared with the same syntax that is used to access it later.

Re: Modern C [pdf]

#308

Post by Watabou »

yekim wrote: post #230
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.

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…

Just curious, not a C developer by any means, but why wouldn't you use a function here instead of a goto? I'm confused how goto would reduce error/improve readability in that example.

Again, not criticizing, genuinely want to know.

Re: Modern C [pdf]

#309

Post by ehsanu1 »

jandrese wrote: post #50
noir_lord wrote: post #41

Earlier quoted context omitted.

Pragmatism over "Oooh Shiny", one of the reasons I have huge respect for the sqlite project ;). Rust looks pretty decent but I'm still in the wait and see stage as well.

I was trying to teach myself some Rust and found the state of the documentation to be very frustrating. The core language is decently documented with the manual, but the standard library documentation was out of date in many places, most annoyingly in the first few hits on Google. I found 5 different ways to read a file on Google, and only one of them still worked. Plus I saw the release notes on the newest version t…

You still have to be a bit careful about finding old posts and old docs on the internet about Rust, given that many APIs have only been stable for a short while.

In general, unless you know your source is up to date, I'd recommend ignoring the internet at large completely when it comes to Rust APIs and just focusing on the official docs for the release that you're using. They're plenty good enough, though you do have to get used to navigating them.

Re: Modern C [pdf]

#310

Post by ArkyBeagle »

paulmd wrote: post #237
yekim wrote: post #225

Earlier quoted context omitted.

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

It's not just that HN does a lot of webdev. It's that even in its element as a "systems language" it's virtually impossible to write 100% safe C/C++ code and guarantee that it will remain safe into the future, even for experts who are making every effort to do it right. There are just too many gotchas with "undefined behavior" and too many clever compilers out there waiting for you to make a mistake. One only needs t…

I think the bottom line is that it simply takes too long to actually become fluent in 'C'. This makes it a horror for open source, where you have to draw on volunteers.

You simply can't just write 'C' without making sure all the details that are necessary to run safely are in scope at all times.

While I agree - the OpenSSL cases certainly show the weakness of the language, there's just no way I'm gonna hang all that on 'C'. Writing protocols and protocol drivers is a fairly tedious sort of skill to attain. We inevitably descend into a counterfactual ... "fantasy" ( sorry; don't mean anything insulting by that - besides I do it too - it is just the nature of counterfactuals ) in which 'C' ends up the villain, when it was a much richer set of failures in play.

Post reply on HN