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

C meeting is over. C23 added:

twitter.com

Post reply on HN
Print view View original

251–260 of 363 posts

Re: C meeting is over. C23 added:

#251

Post by sgt »

CyberRabbi wrote: post #244
bruce343434 wrote: post #39

Earlier quoted context omitted.

I'm going for C, because I am experienced with C and despite it being more tedious, with having to do everything yourself, I stick with it because the compile times, and in fact the compile process, are so much faster and simpler. I really enjoy the direct feedback I can get. I considered C++ but that too had terrible compile times. Ideally a debug build should simply not take longer than 100ms for a codebase that is…

I’m going for C because programming language choice is a matter of personal preference in essence and Rust annoys me.

How does it annoy you? Development velocity, creativity hinderance?

Re: C meeting is over. C23 added:

#252

Post by Findecanor »

mhh__ wrote: post #184
moralestapia wrote: post #158

Earlier quoted context omitted.

>Maybe in another 60 it will get proper strings and arrays. If you think this is missing, there's a big chance you don't "get" C. Also, if you don't know how to properly emulate strings in a safe way in C nowadays (for which plenty of code sample and librariesexist), your skills with the language are quite poor.

Adding so-called fat pointers to C that could be bounds checked would probably instantly eliminate a large fraction of all security issues. Of course, you can emulate these yourself, it's just a struct but not everyone does.

C99 introduced variable-length array parameters and variable-length array pointers together with variable-length arrays (VLA). These take another parameter or variable as a length-parameter. These became optional in C11 together with VLAs (for some reason) but are supposed to again become mandatory in C23. However (yet, for some reason) the pointers can (in the latest published draft, still) only be inside procedures: not in structs or in global variables.

I think it would not be impossible for a C compiler to detect and produce a warning if an index used with such an array-pointer is not checked against the array-pointer's length variable.

This would not make bounds-checks automatic, but the use of these types could make compilers point out when bounds are not checked or checked incorrectly.

Re: C meeting is over. C23 added:

#253

Post by zh3 »

MawKKe wrote: post #118
zh3 wrote: post #77

Earlier quoted context omitted.

Wow, that's annoying. There's a bunch of old code we have that'll need updating (written that way to keep the line lengths down).

...can't you just configure your build system to compile those modules with pre-c23 standard?

Of course. But one of the great things about C is that as a rule nothing breaks with compiler changes (as long as appropriate care has been taken) which this appears to violate.

Re: C meeting is over. C23 added:

#254

Post by chaz72 »

xigoi wrote: post #224
10x-dev wrote: post #86

Earlier quoted context omitted.

Are you going to mix all those languages into one project and somehow use their advantages but steer away from their disadvantages? Sure, other languages have caught up or have improved on some of the features where C shines. Let's remove portability and integration from the feature list, because that's strongly related to C's tenure. Which one of the languages you listed matches the rest of the feature set I brought…

Zig? I personally haven't used it, but based on what I've heard about it, it fulfills these criteria.

That’s what I am betting on - but it isn’t 1.0 yet, and that matters too.

Re: C meeting is over. C23 added:

#255

Post by User23 »

bitwize wrote: post #250
nec4b wrote: post #159

Earlier quoted context omitted.

C must be really amazing compared to Algol than. It powers today's computing infrastructure without having proper boolean type. Are there any widely used applications written in Algol?

The Burroughs MCP operating system and some applications written on top of that. In fact, I believe that was the very first OS to be written entirely in a high-level language. MCP is not today widely used in the same way, say, React or Linux is, but businesses used and depend on it such that it's still sold and supported, as Unisys ClearPath MCP.

I’ve heard that Burroughs had an absolutely world class engineering team in their heyday.

Re: C meeting is over. C23 added:

#256

Post by dzaima »

kaba0 wrote: post #248
dzaima wrote: post #195

Earlier quoted context omitted.

linked lists - true, but at least when you write them you'll be certain of what they do, and, coupled with knowledge of cache performance, precisely how bad they are. About reallocation I don't even mean the copying, but just the code needing to check for the chance overflow on every push. Besides the obvious waste of instructions to check for that, it also clobbers registers even if the branch isn't taken, and thus…

Branch prediction exists so the common case can be made very fast (much faster than jump to this remote pointer), and also, rust uses an optimizing compiler for a reason. Eg., you use a vector inside a for, the vector’s code can be inlined and the checking part be done only at the boundary. Also, one can also manually perform an unchecked push/get/whatever as well.

The common case may be fast, but it's still slower than not having a rare case in the first place. The untaken branch will still affect register allocation (out of the ~15 x86-64 general-purpose registers, only 5 (6 if you count rbp) preserve data after a non-inlined function call in the System-V ABI (of which there will be at least one, ending in malloc somewhere), and the compiler has to accommodate both taken and untaken at the branch end) and will eliminate any hope of SIMD vectorization, among other wrecked optimizations.

Unchecked operations are acceptable if your code has a single hot loop, but if you have a hundred small functions, each taking 1% of the time, you probably won't carefully examine every stdlib function each of them uses and write code to "work around" every unnecessary thing the stdlib does.

Yes, that's a ton of micro-optimization, but micro-optimization can bring a ton of speedup, so I'll take whatever makes it simpler (or not needed in the case where you already know what will happen due to having written it)

Re: C meeting is over. C23 added:

#257

Post by torstenvl »

pjmlp wrote: post #215
rossy wrote: post #190

Earlier quoted context omitted.

The exception? It's standard practice for distros to compile with hardening flags, and if RH submits the bugs they find with Coverity upstream, that protects the 1000s of C projects they package.

Standard practice they say, https://googleprojectzero.blogspot.com/2021/12/this-shouldnt...

Mozilla is not a Linux distro.

You have made dozens of negative (and sometimes rude) comments in this thread. I'm curious why you're spending so much time and energy being negative. If C isn't something you're interested in, why not just ignore it and move on?

Re: C meeting is over. C23 added:

#258

Post by truffdog »

flohofwoe wrote: post #120
flyinglizard wrote: post #53

Earlier quoted context omitted.

Why does it matter if compile time is 100ms or 300ms? At even a second, that’s going to be so negligible in the context of code-compile-debug work. Especially if something like a flash download is involved.

The compilation time difference between C and Rust for nontrivial projects is much bigger than 3x.

Are there features you can ban in your style guide to prevent serious compile time problems?

Re: C meeting is over. C23 added:

#259

Post by jb1991 »

childintime wrote: post #139

> In its London 2019 meeting, WG14 has found consensus to elevate false and true to proper keywords. The committee settled this over a beer, or some other substance? Because the elevation to a proper type is opportunistic at best, and against the spirit of C at worst. Next people celebrate this with the use of capslock. The futility of it all blows my mind :C

> the elevation to a proper type is opportunistic at best, and against the spirit of C at worst

Can you explain what you mean by this?

Re: C meeting is over. C23 added:

#260

Post by sebow »

tpoacher wrote: post #127

For all of us that follow an "I do not want to log in to twitter" philosophy, can someone here please post an alternative link? Incidentally, I'm glad Twitter now blocks you from reading if not signed in. I'm hoping this will encourage the use of alternatives.

There is indeed nitter.I also recommend using an extension for general redirecting.A popular one I use with presets for big sites is Privacy Redirect (ff) but there are also ones for that allow customization (Redirector for example, also ff).
Post reply on HN