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

Weekend projects: getting silly with C

lcamtuf.substack.com

Post reply on HN
Print view View original

21–30 of 118 posts

Re: Weekend projects: getting silly with C

#21

Post by tialaramex »

uecker wrote: post #15
JohnMakin wrote: post #8

My undergrad was entirely in the C language and I’m very glad for it. Sometimes more modern languages can throw me for a loop, no pun intended, but the beauty (and horror) of C is that you are pretty close to the metal, it’s not very abstracted at all, and it allows you a lot of freedom (which is why it’s so foot gunny). I will never love anything as much as I love C, but C development jobs lie in really weird fields…

I force my students to do C development. And it turns out that it is not that hard if you approach it with modern tools which catch a lot of problems. The lack of abstraction is fixed with good libraries. C evolved a lot and many foot guns are not a problem anymore. For example for if (x = 1) you nowaday get a warning. https://godbolt.org/z/79acPPro6 Implicit int, calling functions without prototypes, etc. are hard e…

The warning says to add parentheses, which sure enough silences the warning, your foot, however, still has a bullet hole in it.

Re: Weekend projects: getting silly with C

#23

Post by 8372049 »

JohnMakin wrote: post #8

My undergrad was entirely in the C language and I’m very glad for it. Sometimes more modern languages can throw me for a loop, no pun intended, but the beauty (and horror) of C is that you are pretty close to the metal, it’s not very abstracted at all, and it allows you a lot of freedom (which is why it’s so foot gunny). I will never love anything as much as I love C, but C development jobs lie in really weird fields…

> if they didn’t use the syntax if (1==x) rather than if (x==1). The former will not compile if you accidentally use variable assignment instead of equality operator

No need for Yoda notation. clang will warn of this by default and gcc will do so if you compile with -Wall, which should also be your default.

Re: Weekend projects: getting silly with C

#24

Post by frou_dh »

JohnMakin wrote: post #8

My undergrad was entirely in the C language and I’m very glad for it. Sometimes more modern languages can throw me for a loop, no pun intended, but the beauty (and horror) of C is that you are pretty close to the metal, it’s not very abstracted at all, and it allows you a lot of freedom (which is why it’s so foot gunny). I will never love anything as much as I love C, but C development jobs lie in really weird fields…

> for example I knew a guy that’d auto reject C PR’s if they didn’t use the syntax if (1==x) rather than if (x==1). The former will not compile if you accidentally use variable assignment instead of equality operator

I've seen that one and personally dislike that mindset: Making the code less readable to compensate for a disinterest in using actual static analysis tooling.

Re: Weekend projects: getting silly with C

#25

Post by uecker »

tialaramex wrote: post #21
uecker wrote: post #15

Earlier quoted context omitted.

I force my students to do C development. And it turns out that it is not that hard if you approach it with modern tools which catch a lot of problems. The lack of abstraction is fixed with good libraries. C evolved a lot and many foot guns are not a problem anymore. For example for if (x = 1) you nowaday get a warning. https://godbolt.org/z/79acPPro6 Implicit int, calling functions without prototypes, etc. are hard e…

The warning says to add parentheses, which sure enough silences the warning, your foot, however, still has a bullet hole in it.

The warning is very clear. If you did intend to use the result of an assignment as truth value, you would notice. In any case, did not have a single problem with this type of error in the last decades, working with programmers of various skill levels including beginners.

Re: Weekend projects: getting silly with C

#26

Post by Joel_Mckay »

uecker wrote: post #15
JohnMakin wrote: post #8

My undergrad was entirely in the C language and I’m very glad for it. Sometimes more modern languages can throw me for a loop, no pun intended, but the beauty (and horror) of C is that you are pretty close to the metal, it’s not very abstracted at all, and it allows you a lot of freedom (which is why it’s so foot gunny). I will never love anything as much as I love C, but C development jobs lie in really weird fields…

I force my students to do C development. And it turns out that it is not that hard if you approach it with modern tools which catch a lot of problems. The lack of abstraction is fixed with good libraries. C evolved a lot and many foot guns are not a problem anymore. For example for if (x = 1) you nowaday get a warning. https://godbolt.org/z/79acPPro6 Implicit int, calling functions without prototypes, etc. are hard e…

The libglib-dev with gcc is very handy for toy projects, but only _after_ students try to write their own versions:

https://docs.gtk.org/glib/data-structures.html

It could be fun to do a lab summary after the lists and hashes introduction.

Have a wonderful day, =)

Re: Weekend projects: getting silly with C

#27

Post by MaxBarraclough »

leni536 wrote: post #17
JonChesterfield wrote: post #13

This features the construct switch(k) { if (0) case 0: x = 1; if (0) case 1: x = 2; if (0) default: x = 3; } which is a switch where you don't have to write break at the end of every clause. #define brkcase if (0) case That might be worth using. Compilers won't love the control flow but they'll probably delete it effectively.

Surely the following would work just as well? #define brkcase break;case kinda defeats the purpose of the macro even.

That strikes me as better. The original macro presumably misbehaves if there's more than one statement in a sequence, as the if will only affect the first statement.

Re: Weekend projects: getting silly with C

#28

Post by uecker »

Joel_Mckay wrote: post #26
uecker wrote: post #15

Earlier quoted context omitted.

I force my students to do C development. And it turns out that it is not that hard if you approach it with modern tools which catch a lot of problems. The lack of abstraction is fixed with good libraries. C evolved a lot and many foot guns are not a problem anymore. For example for if (x = 1) you nowaday get a warning. https://godbolt.org/z/79acPPro6 Implicit int, calling functions without prototypes, etc. are hard e…

The libglib-dev with gcc is very handy for toy projects, but only _after_ students try to write their own versions: https://docs.gtk.org/glib/data-structures.html It could be fun to do a lab summary after the lists and hashes introduction. Have a wonderful day, =)

I absolutely I agree that learning to create you own abstractions is an incredible useful skill. It depends though. For a programming course this makes absolutely sense. But for applied problems in, say, biomedical engineering, this does not work. Many students know only a bit of Python, and then it is too much and "too inconvenient" to start from scratch in C. With Python they have a lot of things more easily available, so they make quick progress. This does not lead to good results though! For most of the Python projects, we end of throwing away the code later. Another problem is that students often do not know what they are doing, e.g. the use some statistical package or visualization package and get nicely looking results, but they do not know what it means and often it is entirely wrong. For machine learning projects it is even worse. So much nonsense and errors from copying other people Python code....

Re: Weekend projects: getting silly with C

#29

Post by quietbritishjim »

> The above example will print the value of a, but it won’t be initialized to 123!

It certainly could do though. In C, using an uninitialised variable does not mean "whatever that memory happened to have in it before" (although that is a potential result). Instead, it's undefined behaviour, so the compiler can do what it likes.

For example, it could well unconditionally initialise that memory to 123. Alternatively, it could notice that the whole snippet has undefined behaviour so simply replace it with no instructions, so it doesn't print anything at all. It could even optimise away the return that presumably follows that code in a function, so it ends up crashing or doing something random. It could even optimise away the instructions before that snippet, if it can prove that they would only be executed if followed by undefined behaviour – essentially the undefined behaviour can travel back in time!

Re: Weekend projects: getting silly with C

#30

Post by masklinn »

tialaramex wrote: post #9
mgaunard wrote: post #2

aren't the switch shenanigans important to the duff's device?

Duff is relying on the fact you're allowed to intermingle the switch block and the loop in K&R C's syntax, the (common at the time but now generally frowned on or even prohibited in new languages) choice to drop-through cases if you don't explicitly break, and the related fact that C lets your loop jump back inside the switch. Duff is trying to optimise MMIO, you wouldn't do anything close to this today even in C, no…

> Duff is relying on the fact you're allowed to intermingle the switch block and the loop

That's just a special case of being able to intermingle switch with arbitrary syntax, which is what TFA does, before it jumps to computed gotos.

Post reply on HN