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

361–370 of 396 posts

Re: Modern C [pdf]

#361

Post by CmdrSprinkles »

dang wrote: post #282
CmdrSprinkles wrote: post #267

Earlier quoted context omitted.

Except that this is a discussion on how news and topics are received at HN. So making a projection based on available data is actually quite reasonable and if there is a sample bias, it is a valid one. Because it doesn't matter if there are nine hundred billion hardcore VHDL folk around here. The most popular discussions tend to be tech related to web technologies and the associated tools. If the consistently popular…

You're not making a projection based on data, you're generalizing from things you personally happened to notice, which is practically the definition of sample bias. It's extremely common to do this (I'm not picking on you personally!), but such generalizations have no objective value and lead to repetitive, low-quality discussion, which is why I think we're going to add a guideline asking people not to do it.

Again, the discussion was about why topics like C/C++ are dismissed/disliked around here and I presented an argument based upon observations in threads. That is actually a valid approach.

And if your issue is actually that I very clearly pulled a number out of my arse and went out of my way to make it clear that I had: Are you also going to make it mandatory for everyone to preface every non-cited statement with "in my opinion"?

Look, I get that this is your bread and butter and that it is important for HN to be presented as being THE place for tech and blah blah blah and being pigeonholed into "a site for web and app developers who like silicon valley" isn't necessarily what you want, but trying to pretend that a rule to not "generalize" as a way to not have people speculate and discuss why some topics just aren't particularly welcome here isn't the way to go. Just make it a rule, you aren't fooling anyone.

Also, if you REALLY wanted to improve discussions here: Make a rule against pseudo-technical naval gazing (is there a term for that? "Naval gazing" is more associated with philosophy and potheads) as far too many threads devolve into "We can't help but be introverted because our minds are designed that way and I need to be isolated to code because I need to optimize everything".

Re: Modern C [pdf]

#362

Post by pawadu »

steveklabnik wrote: post #183
pawadu wrote: post #99

Earlier quoted context omitted.

Fair enough, but it didn't used to be like that: https://scialex.github.io/reenix.pdf

Which part of this paper is the part you're worried about?

The second half of the paper is mostly about challenges in using Rust. Some were related to the way the language handles data (i.e. challenges of sharing data among threads without using unsafe code), but there was also some that are related to the compiler and the standard libraries.

The authors mentions allocation in particular (to be honest I did not really understand his problem). He also writes about the standard library being too large while the tools don't support bare metal projects out of the box and that the compiler emits a lot of code that depends on the standard libraries.

Of course, the paper is more than a year old so all these issues can have been fixed by now. Maybe you can comment on that?

Re: Modern C [pdf]

#363

Post by loup-vaillant »

uryga wrote: post #301
loup-vaillant wrote: post #141

Earlier quoted context omitted.

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.

Well, like the sibling comment, I can only point to the standard. I'll give one example: the segmented memory model. In C, the difference between two pointers is a valid operation iff they point to the same object (or one slot past it). So it works if it's the same array or malloc() block, but something as simple as

  int a;
  int b;
  ptrdiff_t d = &b - &a;
is undefined. Modern computers, including most embedded platforms, have a flat memory model by now, and could implement the operation above without problem.

Another difference I know of is signed integer overflow. Most platforms use a 2's complement architecture, where signed overflow simply wraps around. In C, such an operation is undefined.

Yet another difference relates to pointer aliasing. On most platform, a pointer is just a pointer to a memory slot. In C, it is assumed for optimization purposes that pointers of different types cannot point to overlapping regions. This prevents practical stuff like type punning, for which you have to use unions.

Re: Modern C [pdf]

#365

Post by imron »

renlo wrote: post #283
imron wrote: post #185

Earlier quoted context omitted.

> I would not let that line pass code review. At least it's not for (size_t i = 9; i >= 0; --i) :-)

Your for loop works, whereas the one in the parent comment would run forever, correct? Is there something I'm missing here? edit: Ok, looking at it again the parent example is probably going to overflow or something right?

> Is there something I'm missing here?

Yes (see other replies), and it's precisely the reason why this code shouldn't pass code review.

At first glance the first example looks like it should fail but in fact works. The second example I provided looks like it should work, but in fact loops infinitely.

The first one is tricky and nifty, but prone to bugs. Using signed counters is better way to go about it.

Re: Modern C [pdf]

#366

Post by mixedCase »

jimmaswell wrote: post #353
mixedCase wrote: post #214

Earlier quoted context omitted.

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.

I doubt the RoI is much more than if these were just suppressible warnings instead of errors, which work out great in C#.

>which work out great in C#.

They're greatly ignored in the real world.

Re: Modern C [pdf]

#367

Post by junke »

sidlls wrote: post #328
junke wrote: post #289

Earlier quoted context omitted.

I mean something like Ada's pragmas: https://en.wikibooks.org/wiki/Ada_Programming/Pragmas/Suppre...

Yes (Rust's "unsafe" blocks serve the same purpose), and my point is you're narrowing the definition of "explicit" to exclude C or C++ by definition. And that isn't exactly a fair, in my view.

There is no doubt that C, by definition, opts out from performing bound checkings. But if bounds were always checked by default (implicitly), then you would have to opt-out explicitly, which is a safer approach, because all else being equal, in case of a programming mistake, the code ends up not being vulnerable to that specific kind of attack.

Re: Modern C [pdf]

#368

Post by junke »

sidlls wrote: post #211
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.

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

My view is that lack of provable safety should be resolved by defensive code (runtime checks). And then, you are safe (if safety is important in your code, which probably should by default in a professional setting).

Re: Modern C [pdf]

#369

Post by fb03 »

wangchow wrote: post #169
fb03 wrote: post #151

ITT: Heated arguments and zealotry. In resume: "C is outdated, its ubiquitousness is just a historical accident" "Better tools exist to do this job" "C is not needed anymore" (Yet no contender has ever come close to it, hehehe --my2c) There, saved you a ton of reading time.

A time will come when our entire concept of programming will shift due to advances in hardware unlike what we have today. Consider quantum computers or some biological machine etc. Those who use C and assembly I imagine would be better equipped to understand the new paradigms. It's best to understand how to implement data structures in their most rudimentary form because implementing them on new platforms becomes eas…

I agree!

I also believe efforts like LLVM are actively trying to 'bridge the gap' between both worlds (totally raw VS fully dynamic/scripted). Stuff like emscripten is enabling the "old farts" and the "newfags" to share common ground, and that's amazing... I just hope these youngsters keep learning stuff instead of just piling framework after framework after the new 'hot shit' gets released in a 6 month timeframe.. really, adhd is in full effect, specially in the webdev world, and imho that's hurtful.

o/

Re: Modern C [pdf]

#370

Post by kruhft »

sea6ear wrote: post #337
kruhft wrote: post #233

The best book I had for learning more about C was titled 'Writing Bug Free Code For Windows' from the late '90s early 2000's. It contained a complete object oriented system using simple header tricks and data hiding plus covered all sorts of pre-processor tricks that aren't evident until you really dig into what C can really do. I'm sure it's impossible to find now, but recommended.

Is this the book you are talking about [1]? If so, it looks like the author has put it online for free. [1] https://www.duckware.com/bugfreec/index.html

There you go! Thanks :)
Post reply on HN