Another nice convenience: a new #elifdef preprocessor directive to replace longhand #elif defined().
C meeting is over. C23 added:
271–280 of 363 posts
Re: C meeting is over. C23 added:
#272Earlier quoted context omitted.
You once claimed C requires UNIX like OS to run.
I claim it yet again on this very comment. Without UNIX spreading with its free beer into universities, C would have been a footnote on the history of system programming languages.
Much more importantly, without UNIX and free beer TCP/IP there's a fair chance the Internet isn't the Network and none of this (gestures at HN and the Web) happens. That's a much bigger impact than C which is just a programming language, even if you count the influence of NUL-terminated strings, and all the semi-colon languages (including even Javascript and Rust, which are very different from C but preserve the enthusiasm for semi-colons) the Internet as Network makes more difference.
In particular it's possible X.25 could have won. JANET (the tertiary education network in the United Kingdom) was exclusively doing X.25 until 1991, when it tries an experiment offering IP. Unsurprisingly free beer TCP/IP offers a cornucopia of interesting new toys and sites are very enthusiastic about JIPS (the experimental IP service) so that by 1992 the IP service is no longer an experiment but the primary service, with X.25 maintained only until 1997.
You do get the Network anyway of course, that's what everything is leading up to after Shannon, but you probably get an X.25 flavoured Network instead of the Internet, or some other system coming from another direction, and broad deployment might have been delayed into the early 21st century rather than the 1990s depending on exactly how things work out. Stallman's GNU project doesn't happen, Tim's toy hypermedia system either doesn't exist or is a small inconsequential experiment largely unknown outside hypermedia fanatics, and Linus Torvalds probably doesn't make an operating system kernel for his 386 microcomputer. It's a very different environment, C is small potatoes by comparison.
Re: C meeting is over. C23 added:
#273Earlier quoted context omitted.
C isn’t that small, compare it to a Zig hello world. Fast is relative — due to C not having good expressive/abstracting powers, it will leave you to inferior solutions, eg. counting string length multiple times at call sites, vs C++’s small string optimization, which is simply not possible in a user-ergonomic way in C. Regarding obviousness, I would add UB here, so Zig for example would beat it. C is not any closer t…
>due to C not having good expressive/abstracting powers I disagree, if anything, C's scantness forces you to abstract things much properly, unless you plan to write pages of boilerplate code here and there.
With all due respect - how do you write a string library in C then? Char* is not one.
Re: C meeting is over. C23 added:
#274Earlier quoted context omitted.
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…
Feel free to wrap it into a repr(transparent) type which exposes the unsafe operations by default.
But I seriously doubt that programs would benefit much from these micro-optimizations - there are rare and unfortunate cases where indeed there is no one single bottleneck for a program and thus there is no simple way to improve performance, but the vast majority of programs spend all their life in a tight hot loop, and anything else doesn’t matter in the slightest - hell, as mentioned C gets away with as many linked data structure as they want, but writing those in goddamn bash would suffice as well.
Re: C meeting is over. C23 added:
#275Earlier quoted context omitted.
I agree that Rust is simpler than C++ (in some ways), but I’d say it is far more complex than C.
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.
Re: C meeting is over. C23 added:
#276I can't tell if this is serious. Surely if you're still using C now it's for legacy reasons. And if using it for legacy reasons you are likely stuck using an old C standard. So who will use C23?
I'll keep writing things in C, because it maximizes my productivity and gives me extra time to make it secure (less time than it would require to write it in Rust in the first place).
Re: C meeting is over. C23 added:
#277Earlier quoted context omitted.
I surely get C, having to deal with its casualties in DevSecOps. I have been "getting" C since 1992, across Xenix, DG/UX, HP-UX, Solaris, AIX, FreeBSD, Linux, Amiga, Windows 3.x,.....
Well, then, you must know it's not really a big deal to write code with proper memory checks.
It's a big deal, you need about 1/3 of sel4 proofs
Re: C meeting is over. C23 added:
#278Earlier quoted context omitted.
Manual says > If size is 0, then malloc() returns either NULL, or a unique pointer value that can later be successfully passed to free(). So it's not really an array of bytes of size 0.
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.
Re: C meeting is over. C23 added:
#279Earlier quoted context omitted.
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…
Feel free to wrap it into a repr(transparent) type which exposes the unsafe operations by default. But I seriously doubt that programs would benefit much from these micro-optimizations - there are rare and unfortunate cases where indeed there is no one single bottleneck for a program and thus there is no simple way to improve performance, but the vast majority of programs spend all their life in a tight hot loop, and…
That depends on the project. There definitely are projects in which micro-optimizations such as this wouldn't be beneficial for one reason or another, but there definitely also are ones where they're make-or-break. For those, C is pretty good, and you're not fighting against the language (or the core intent of the language at least).
(I'd guesstimate that micro-optimizations would go a very long way in improving performance of nearly every program anywhere, but I don't have much data on that besides the couple projects where I've tried to care about performance, and having achieved pretty decent results)
Re: C meeting is over. C23 added:
#280Earlier 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.
Cool, I will definitely look it up.