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

Modern C (2019)

gustedt.gitlabpages.inria.fr

Post reply on HN
Print view View original

11–20 of 57 posts

Re: Modern C (2019)

#11

Post by JohnFen »

neutrono wrote: post #5
david2ndaccount wrote: post #2

I enjoy programming in C a lot, though I wish they would fix C's biggest mistake[1]. [1] https://digitalmars.com/articles/C-biggest-mistake.html >

The declaration syntax and the lack of a proper module/namespacing system is also a mistake, but perhaps not as big as the way arrays decays into pointers. Implicit conversions I suppose could also be classified as a mistake.

What you're calling "mistakes" look to me like intentional design decisions made in order to optimize for specific kinds of problems.

C is not a high level language, nor should it be. If you're doing the sort of work that is better suited for a high level language, then using a different language is the right call.

Re: Modern C (2019)

#12

Post by kristopolous »

It looks like an introductory C programming book.

I was hoping for it to be a "hello experienced C programmer, here's new stuff that's happened in the past 20 years" kind of thing which would be useful.

I think most people have a hard time keeping up with the progress of all the technologies they use unless they've got a pretty narrow focus.

For instance, I learned make in the 90s. I should probably go read up on what's happened in the past 25 years or so. Probably lots of cool stuff.

Edit: it looks like just reading the release notes is probably sufficient. There's indeed lots of interesting new things

Re: Modern C (2019)

#13

Post by anovikov »

remexre wrote: post #9
jylam wrote: post #4

Earlier quoted context omitted.

C biggest "mistake" (there are historical reasons for this, though, but it doesn't make it acceptable nowadays) is the concept of undefined behavior, period.

Should a compiler be allowed to optimize: int x = 0; int y = 42; foo(&x); bar(y); to: int x = 0; foo(&x); bar(42); without performing analysis on foo? If so, how can that optimization be legal without UB?

How is this UB? foo() won't have any access to y so won't be able to modify it, so we can be more or less certain that y is still 42 when bar() is called? What is it that i'm missing?

Re: Modern C (2019)

#14

Post by kevin_thibedeau »

remexre wrote: post #9
jylam wrote: post #4

Earlier quoted context omitted.

C biggest "mistake" (there are historical reasons for this, though, but it doesn't make it acceptable nowadays) is the concept of undefined behavior, period.

Should a compiler be allowed to optimize: int x = 0; int y = 42; foo(&x); bar(y); to: int x = 0; foo(&x); bar(42); without performing analysis on foo? If so, how can that optimization be legal without UB?

Y is never visible from foo()s scope. You'd have to employ ABI specific stack manipulation to get to it. Optimization in the outside frame doesn't depend on foo().

Re: Modern C (2019)

#15

Post by torstenvl »

jylam wrote: post #4
david2ndaccount wrote: post #2

I enjoy programming in C a lot, though I wish they would fix C's biggest mistake[1]. [1] https://digitalmars.com/articles/C-biggest-mistake.html >

C biggest "mistake" (there are historical reasons for this, though, but it doesn't make it acceptable nowadays) is the concept of undefined behavior, period.

I'm okay with undefined behavior, but the language should revert back to the original (an exhaustive list of permissible behavior by the host when the C abstract machine's behavior is undefined) rather than the current mere list of examples of possible behavior by the host.

Re: Modern C (2019)

#16

Post by pornel »

jylam wrote: post #4
david2ndaccount wrote: post #2

I enjoy programming in C a lot, though I wish they would fix C's biggest mistake[1]. [1] https://digitalmars.com/articles/C-biggest-mistake.html >

C biggest "mistake" (there are historical reasons for this, though, but it doesn't make it acceptable nowadays) is the concept of undefined behavior, period.

On the contrary, I don't think C would have been so ubiquitous without it. People use C for maximum speed and efficiency. When maximum speed isn't a requirement, there are plenty of more productive and less footgunny languages to choose from. Without the things that C allows to be ignored during optimization, you either wouldn't have compilers that optimize the "simple" language equally well, or you'd have to make the language bigger to give all the right hints and guarantees where they're needed.

I see UB commonly characterized as compiler being mean for silly reasons, with implication that compilers could just stop doing the bad UB and do the good UB, but that isn't accurate or realistic view. The creeping UB is just a symptom of how optimization passes are implemented, and they would be exponentially harder to implement equally well without the concept of UB. "Just do what I mean" is not a well-defined compilation target, and there are tons of surprisingly bad performance issues. e.g. without signed overflow indexing of arrays by int could not use 64-bit CPU's addressing modes, because they overflow differently. You can use size_t, but good luck being diligent about it in a language that loves its ints.

Re: Modern C (2019)

#17

Post by tyler569 »

kevin_thibedeau wrote: post #14
remexre wrote: post #9

Earlier quoted context omitted.

Should a compiler be allowed to optimize: int x = 0; int y = 42; foo(&x); bar(y); to: int x = 0; foo(&x); bar(42); without performing analysis on foo? If so, how can that optimization be legal without UB?

Y is never visible from foo()s scope. You'd have to employ ABI specific stack manipulation to get to it. Optimization in the outside frame doesn't depend on foo().

And that ABI specific stack manipulation would be UB, so the optimizer can assume it doesn't happen. With no UB, that's not true.

Re: Modern C (2019)

#18

Post by remexre »

anovikov wrote: post #13
remexre wrote: post #9

Earlier quoted context omitted.

Should a compiler be allowed to optimize: int x = 0; int y = 42; foo(&x); bar(y); to: int x = 0; foo(&x); bar(42); without performing analysis on foo? If so, how can that optimization be legal without UB?

How is this UB? foo() won't have any access to y so won't be able to modify it, so we can be more or less certain that y is still 42 when bar() is called? What is it that i'm missing?

That's it -- the optimization is legal because there's no way foo() could modify y, because any (&x)[1] = 20 shenanigans would be UB.

This is how UB is used in optimizations; it's (usually) not that the compiler is finding positions where UB occurs and explicitly choosing to perform mischief, it's performing a bunch of simple and obviously-what-you-want rewrites that are only correct because of UB; otherwise, arbitrary pointer writes are too powerful.

Re: Modern C (2019)

#19

Post by dang »

david2ndaccount wrote: post #2

I enjoy programming in C a lot, though I wish they would fix C's biggest mistake[1]. [1] https://digitalmars.com/articles/C-biggest-mistake.html >

Past discussions on that:

C's Biggest Mistake - https://news.ycombinator.com/item?id=27567311 - June 2021 (8 comments)

C’s Biggest Mistake (2009) - https://news.ycombinator.com/item?id=24454369 - Sept 2020 (374 comments)

Conflating pointers with arrays: C's biggest mistake? (2009) - https://news.ycombinator.com/item?id=17585357 - July 2018 (254 comments)

Walter Bright on C's Biggest Mistake - https://news.ycombinator.com/item?id=1014533 - Dec 2009 (47 comments)

Re: Modern C (2019)

#20

Post by [deleted] »

remexre wrote: post #18
anovikov wrote: post #13

Earlier quoted context omitted.

How is this UB? foo() won't have any access to y so won't be able to modify it, so we can be more or less certain that y is still 42 when bar() is called? What is it that i'm missing?

That's it -- the optimization is legal because there's no way foo() could modify y, because any (&x)[1] = 20 shenanigans would be UB. This is how UB is used in optimizations; it's (usually) not that the compiler is finding positions where UB occurs and explicitly choosing to perform mischief, it's performing a bunch of simple and obviously-what-you-want rewrites that are only correct because of UB; otherwise, arbitra…

[deleted]
Post reply on HN