Live data from Hacker News

C meeting is over. C23 added:

twitter.com

281–290 of 363 posts

Re: C meeting is over. C23 added:

#281
post #251

Earlier quoted context omitted.

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?

Visually it’s annoying. It’s like the comic sans of programming languages.

Re: C meeting is over. C23 added:

#282
post #278

Earlier quoted context omitted.

What qualifies something as a "real" array of bytes? All RAM is an array of bytes, so any pointer to real memory(vs. virtual memory) is a pointer to an array of bytes.

C mandates that arrays have positive size. It's not really a discussion about what the target platform does, rather it's what the abstract C machine mandates.

Oh sure - malloc() returns a pointer to sequentially-addressable bytes, not a C array. So even if the size were greater than 0, it would prove nothing about C arrays.

Re: C meeting is over. C23 added:

#283
post #177

Earlier quoted context omitted.

That depends on how you define complexity. It is far easier to write a working program without memory leaks, various types of vulnerabilities, and undefined behavior in Rust than it is in C.

It depends on what level of security you need. If you're writing a 3D game engine, a minor memory leak probably isn't worth the extra time required to write it in Rust. Even if you're writing a kernel, fuzzing and formal verification can get you 99.999 of the way to the guarantees of Rust.

I feel like writing Rust is a whole lot faster and less error-prone than writing something in C. But even assuming that it's slower, it's definitely much faster than writing C and doing formal verification. Naturally formal verification can help with other properties besides memory safety, and as far as I am aware Rust is still lacking a formal semantics so when you go all-in on formal methods C can reach a provable level of quality that Rust currently cannot. But very few people develop software that way.

Re: C meeting is over. C23 added:

#284

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.

[deleted]

Re: C meeting is over. C23 added:

#285

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.

You can paste this on console to remove the popup

(function () { document.querySelector('html').style = ''; document.querySelector('.css-1dbjc4n.r-aqfbo4.r-1d2f490.r-12vffkv.r-1xcajam.r-zchlnj.r-ipm5af').remove(); })()

Re: C meeting is over. C23 added:

#286
post #215

Earlier quoted context omitted.

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?

> Mozilla is not a Linux distro.

That's true. But should I interpret this to mean, "All that stuff about how careful we are doesn't actually apply to any third party software, we only do that for code we wrote" ? Because the thing about a Linux distro is that it's overwhelmingly third party software.

If that stuff does apply to NSS, then all that hard work apparently missed this pretty serious bug that could not have happened in a safe language.

Re: C meeting is over. C23 added:

#287
post #233
post #223

Earlier quoted context omitted.

There are plenty of C compilers written in C. Large compiler suites for C/C++ are usually written in C++. But as a contributor to GCC, I can say that large parts of the code still look very much like C.

Plenty of compilers... right. If you cannot compile GCC with a C compiler, it isn't C.

Trying to win a pointless argument based on pedantic logic that misses the point.

Re: C meeting is over. C23 added:

#289
post #45

Removing K&R style function prototypes though is kind of big. I remember when one of the Objective-C upgrades started enforcing K&R. I don't think ObjC will be upgraded to C23 (ever, as it's a language being deprecated now I presume) so it will be stuck with K&R... while the rest will move on? Could someone also explain what this means for pure C in terms of compatibility? If there's void foo(); would the meaning of…

What's being removed in C23 is the ancient K&R syntax for function definitions: int max(a, b) int a, b; { return a>b?a:b; } My understanding is that C23 does not change the meaning of function declarations. So "void foo();" remains a declaration of a function accepting an unknown number of parameters.

I'm particularly unhappy that K&R declarations are going away without https://www9.open-std.org/JTC1/SC22/WG14/www/docs/n2780.pdf being added to replace them. Now there's some functions that you can't write anymore.

Re: C meeting is over. C23 added:

#290
post #225

Earlier quoted context omitted.

Well, UNIX is surely responsible for C becoming popular (if not its being a thing in the first place).

I'm not arguing that it is not? It's funny though how many people saw value in C but not in Algol. Maybe C has something going for it?

Who, except for people too young to know better, saw value in C but not in Algol? The Bell Labs folks obviously thought enough of Algol such that C is a descendant in the family of Algol-like languages. Algol was widely used in Europe whereas in the U.S. we made do with Fortran, Cobol, and, I think to a lesser extent, PL/I, although the latter had many Algol-like features at the time. (And Fortran evolved to have many of those features; I suppose Cobol also, but I'm not familiar with its post-1981 history.)

Taking a contrarian view to everyone else in this thread, I don't think Unix rocketed C to stardom - Turbo C did. Turbo Pascal was very very popular for PC programming and was eventually supplanted by Turbo C and Turbo C++. Without Turbo C, I think C would have probably become just another niche language used on a niche OS, Unix.

And in line with what you say in another comment, commercial OSes -- including VMS -- were very powerful and much more popular than Unix. In 1982, a single VAX 11/780 running VMS with 4 and 8 MB of RAM could support 10s of programmers editing, compiling, debugging, and testing code. VMS was also a real-time operating system that we used in production to control/monitor/perform-I/O hardware devices handling LANDSAT image data. And Unix is still trying to figure out async I/O ... (Most of my career has been spent on Unix, but I appreciate other operating systems I've worked on as well.)

Post reply on HN