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

181–190 of 396 posts

Re: Modern C [pdf]

#181

Post by mathw »

module0000 wrote: post #121
adamnemecek wrote: post #113

Earlier quoted context omitted.

How detailed is your knowledge of undefined behavior?

We know when undefined behavior will occur(the specs are written very clearly), but not what will happen when it occurs. Our job as competent C programmers is to avoid undefined behavior. C isn't hard(perhaps tedious to do correctly) - it does exactly what you tell it to.

It does, but it's unnecessarily difficult to keep track of all the places undefined behaviour might occur and make sure you don't step into any of them under any conditions ever.

We shouldn't have to work like this anymore. C's been an amazing language, but it's getting time to gently, respectfully, move on. There's active and interesting development in alternatives which attempt to retain C's primary advantages while also allowing the compiler to keep you out of trouble as much as possible.

We have hugely powerful computers available to use as developers. We can contemplate designing and compiling languages with a complexity which would have completely defeated the systems available when C was developed. Why shouldn't we use some of that power to make our lives easier?

Re: Modern C [pdf]

#182

Post by steveklabnik »

mitchty wrote: post #12
cygx wrote: post #10

Earlier quoted context omitted.

Would anyone choose C for a new systems project with no legacy baggage or dependencies, in a world with Rust and Go? Note that Go does not entirely compete in the same space, and Rust is only starting to gain traction.

Also if anyone is talking about systems programming, it would be beneficial if you specify what that means. I've seen people consider "systems" programming as relating to building web services. Traditionally systems programming would be more kernel level and utilities/daemons. Rust might be OK to start using for the latter, but its very much not yet where I'd start using it for new things for either of the traditiona…

> Given how much it changes I would NOT want to bet on using it for at least 5 years.

Rust may be changing, but it's almost entirely _additions_. We've been stable for roughly 18 months now.

Re: Modern C [pdf]

#183

Post by steveklabnik »

pawadu wrote: post #99
rvense wrote: post #95

Earlier quoted context omitted.

I think it now amounts to adding a line to the file that tells it to not use the standard library. I've seen smaller projects that did it, and it was nothing like crazy hacks.

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?

Re: Modern C [pdf]

#184

Post by verandaguy »

pawadu wrote: post #62

The author has also been involved in development of "musl", a modern C11 compliant standard library implementation: http://www.musl-libc.org https://gustedt.wordpress.com/2014/10/14/musl-1-1-5-with-ful...

I've been following musl for a little while because of its support for C11 threads. I'm surprised that none of the bigger libraries haven't implemented that.

Re: Modern C [pdf]

#185

Post by imron »

colanderman wrote: post #156

While I like a lot of what's in here, for (size_t i = 9; i is a pretty terrible example to put in the second chapter. I would not let that line pass code review. There is no need or place for cutesy cleverness in C. EDIT: Ugh, just found this too: isset[!!largeA[i]] += 1; Not only is that confusingly cutesy, but largeA[i] is a double . Please DON'T write – or encourage beginners to write! – such smug code! EDIT2: In…

> I would not let that line pass code review.

At least it's not

    for (size_t i = 9; i >= 0; --i)
:-)

Re: Modern C [pdf]

#186

Post by y_u_no_rust »

pcwalton wrote: post #176
pawadu wrote: post #98

Earlier quoted context omitted.

Well, there are two types of people in this world 1. the type that do something 2. the type that claim they could do it better than the first group (this is by no means limited to programming, it is for example pretty common in politics) So please show me an OS written in Go or Rust or Ruby or Python or Java that people can actually use for day-to-day tasks.

I've been working full time for years on a browser written in Rust. Which category am I in? Yes, C++ is very entrenched. That is a problem . We should be fixing that .

I'm still waiting for my mozilla javascript phone bro

Rust is a neat a project and all but it's still slowly moving out of neat toy territory

Re: Modern C [pdf]

#187

Post by yoha »

colanderman wrote: post #156

While I like a lot of what's in here, for (size_t i = 9; i is a pretty terrible example to put in the second chapter. I would not let that line pass code review. There is no need or place for cutesy cleverness in C. EDIT: Ugh, just found this too: isset[!!largeA[i]] += 1; Not only is that confusingly cutesy, but largeA[i] is a double . Please DON'T write – or encourage beginners to write! – such smug code! EDIT2: In…

Decrementing loops is the one place where I have indulged in some trickery. I do:

    for (size_t i = 9; i --> 0; )
This has the advantage to be very easy to pattern-match once known. Obviously, for a beginner, I would just do:

    for (int i = 9; i >= 0; i -= 1)

Re: Modern C [pdf]

#188

Post by cygx »

colanderman wrote: post #156

While I like a lot of what's in here, for (size_t i = 9; i is a pretty terrible example to put in the second chapter. I would not let that line pass code review. There is no need or place for cutesy cleverness in C. EDIT: Ugh, just found this too: isset[!!largeA[i]] += 1; Not only is that confusingly cutesy, but largeA[i] is a double . Please DON'T write – or encourage beginners to write! – such smug code! EDIT2: In…

I would not let that line pass code review.

Obviously. However, it is an appropriate example if your goal is to teach the intricacies of the C language. You're right that if you provide such an example this early, it could perhaps use some additional commentary.

Not only is that confusingly cutesy, but largeA[i] is a double.

That was the point of the exercise: !! is an idiom to convert to boolean (which happen to be integral in C) and something a C programmer (or JavaScript programmer, for that matter) should be familiar with.

This is flatly untrue on x86 and I suspect many other architectures.

Agreed.

Re: Modern C [pdf]

#189

Post by anon1385 »

bluetomcat wrote: post #138
rileymat2 wrote: post #126

Earlier quoted context omitted.

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.

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.

>Compilers are also mature enough to issue warnings about the use of uninitialized variables

That depends on the compiler. It's not true with GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501

Re: Modern C [pdf]

#190

Post by sacado2 »

pjmlp wrote: post #94
pawadu wrote: post #65

Earlier quoted context omitted.

And yet, the OS and the browser you used to type this comment was written in C or a C-derivative like C++.

Historical accident. It could have been written in any other language that compiled to native code, if we had more options available.

The Oberon operating system is as old as linux, yet I'm pretty sure you use the latter more often than the former.
Post reply on HN