Earlier quoted context omitted.
does any distro uses clang? I thought all linux kernels were compiled using gcc.
Chimera does, it also has a FreeBSD userland AFAIU. https://chimera-linux.org/
hm this one is interesting. Thanks for sharing!
-fbounds-safety: Enforcing bounds safety for C
111–120 of 129 posts
Re: -fbounds-safety: Enforcing bounds safety for C
#112Earlier quoted context omitted.
Only statement expressions, but one can also implement this without them.
Still, please standardize them :). I don't use much C but if you add them to the standard they'll probably trickle down to C++ compilers by 2045 and I'll have a good 10 years to use them before I retire.
You are not happy with immediately invoked lambda expressions?
Re: -fbounds-safety: Enforcing bounds safety for C
#113Earlier quoted context omitted.
Still, please standardize them :). I don't use much C but if you add them to the standard they'll probably trickle down to C++ compilers by 2045 and I'll have a good 10 years to use them before I retire.
You are not happy with immediately invoked lambda expressions?
Well, I'll take them over the nothing you're giving me :D
But in all seriousness, I want this:
struct Result { int value; int err; };
#define TRY(res) \
({ \
Result _res = res; \
if (failed(res)) return res; \
res.value; \
})
Result f1(...) { ... }
Result f2() {
int res = TRY(f1(...)); // Re: -fbounds-safety: Enforcing bounds safety for C
#114Earlier quoted context omitted.
You are not happy with immediately invoked lambda expressions?
Well, I'll take them over the nothing you're giving me :D But in all seriousness, I want this: struct Result { int value; int err; }; #define TRY(res) \ ({ \ Result _res = res; \ if (failed(res)) return res; \ res.value; \ }) Result f1(...) { ... } Result f2() { int res = TRY(f1(...)); // Can't be done with lambdas since the macro needs to return out of the actual function, not the lambda. Pretty much rust question m…
I see, thanks! There is general consensus that statement expressions should become part of ISO C, but some lack of time to get it done. I am not part of WG21 though, so can't say anything about C++.
Re: -fbounds-safety: Enforcing bounds safety for C
#115Earlier quoted context omitted.
The feature is only on SPARC, not x86. Oracle killed in-house SPARC development in 2017, and they abandoned OpenSPARC after they acquired Sun, so it's effectively a dead architecture. The software won't work without the hardware to run it on.
Fujsitsu also does SPARC, and contrary to HP-UX, people still do buy Solaris. EDIT: https://www.oracle.com/servers/sparc/ https://www.fujitsu.com/global/products/computing/servers/un... Finally, it is up to Intel and AMD to come up with hardware memory tagging, so far they have messed up all attempts, with MPX being the last short lived one.
Even Fujitsu has been moving away from SPARC. What was the last SPARC Fujitsu designed?
Re: -fbounds-safety: Enforcing bounds safety for C
#116Earlier quoted context omitted.
I've been programming for long; the ratio of memory errors to logic bugs in production is so low as to be non-existent. My last memory error in C code in production was in 2018. Prior to that it I had a memory error in C code in production in 2007 or 2008. In C++, I eventually gave up trying to ship the same level of quality and left the language altogether.
The wider industry data gathered indicates that for memory unsafe languages 80% of issues are due to memory vulnerabilities, including mature codebases like Linux kernel, curl, V8, Chrome, Mach kernel, qemu etc etc etc. This doesn’t mean that logic bugs are less common, it just means that memory safety issues are the easiest way to get access. As for why your experience may be different, my hunch is that either your…
[dead]
Re: -fbounds-safety: Enforcing bounds safety for C
#117Earlier quoted context omitted.
Sorry, I didn’t misremember but I wrote down without proof checking (see another comment where I got it right). I did indeed mean 80% of security vulnerabilities are caused by memory safety issues. For EMV you had C connected directly to the network under a steady stream of attacks and only had an issue once? I find that hard to believe. What’s more likely is a Java websever frontend talking to some C processing / cr…
> For EMV you had C connected directly to the network under a steady stream of attacks and only had an issue once? I find that hard to believe. What’s more likely is a Java websever frontend talking to some C processing / crypto EMV terminals. No Java involved. > As a famous quote states, it’s ok if your code has an uptime of 3 minutes until the first bug if the bomb explodes in 2 Look, first you commented that it's…
EMV terminals are not under daily cybersecurity attack - you need to have physical access unless you designed your system weirdly. You probably had loads of vulnerabilities. But also depending on when you did it, all you had to process was a bar code which is also isn’t some super complicated task.
I’m not trivializing the safety of munitions. I’m attempting to highlight that safety and stability in a munitions context is very different and memory safety issues could easily exist without you realizing. My overall point is that you are silently making the argument that C programmers (or programmers in general) used to be better, which is a wild argument to be making about a culture in which fuzzing didn’t even exist as a concept. You’re also confusing memory safety with implying a crash. That simply isn’t the case - it’s more often exploitable as a security vulnerability than an immediate crash by violating assumptions made that weren’t in the happy path of those microwaves and security systems. That millions of devices were and still are routinely exploitable.
You’re also making a fallacious line of reasoning that the C today is the same C that was in use in the 80s, 90s, and 2000s. It’s not and has gotten harder and more dangerous because a) multi threading became more of a thing and b) compiler authors started exploiting “undefined” behaviors for extra optimization.
It’s just wild for me to encounter someone who believes C is a safe language and is suitable to connect to I/O too when there’s so many anecdotal and wide statistical evidence gathered that that’s not the case. Even SQLite, the darling of the C community, is not safe if asked to open arbitrary SQLite files - there’s various security attacks known and possible.
Re: -fbounds-safety: Enforcing bounds safety for C
#118Earlier quoted context omitted.
> For EMV you had C connected directly to the network under a steady stream of attacks and only had an issue once? I find that hard to believe. What’s more likely is a Java websever frontend talking to some C processing / crypto EMV terminals. No Java involved. > As a famous quote states, it’s ok if your code has an uptime of 3 minutes until the first bug if the bomb explodes in 2 Look, first you commented that it's…
EMV terminals are not under daily cybersecurity attack - you need to have physical access unless you designed your system weirdly. You probably had loads of vulnerabilities. But also depending on when you did it, all you had to process was a bar code which is also isn’t some super complicated task. I’m not trivializing the safety of munitions. I’m attempting to highlight that safety and stability in a munitions conte…
> EMV terminals are not under daily cybersecurity attack - you need to have physical access unless you designed your system weirdly.
They are under daily attack - in public, at tills, operated by minimum-wage earners.
> You probably had loads of vulnerabilities.
Sure. Hundreds of thousands of terminals sitting in the field, networked, under the control of minimum wage employees, each holding credit card details for hundreds of cards at a time...
Yeah, you're right, not a target at all!
> But also depending on when you did it, all you had to process was a bar code which is also isn’t some super complicated task.
You are hopelessly naive. Even in the magstripe era, certification was not easy.
> It’s just wild for me to encounter someone who believes C is a safe language
When did you meet this person?
Look, the bottom line is, the errors due to memory safety in programs written in C is so small it's a rounding error. It's not even statistical noise. You spent your life surrounded by these programs that, if they went wrong, would kill you, and yet here you are, not only arguing from a place of ignorance, you are reveling in it.
Just out of interest, have you ever used an LLM to write code for you?
Re: -fbounds-safety: Enforcing bounds safety for C
#119Earlier quoted context omitted.
Fujsitsu also does SPARC, and contrary to HP-UX, people still do buy Solaris. EDIT: https://www.oracle.com/servers/sparc/ https://www.fujitsu.com/global/products/computing/servers/un... Finally, it is up to Intel and AMD to come up with hardware memory tagging, so far they have messed up all attempts, with MPX being the last short lived one.
Even Fujitsu has been moving away from SPARC. What was the last SPARC Fujitsu designed?
What matters is that they are still selling them.
Re: -fbounds-safety: Enforcing bounds safety for C
#120Niklaus Wirth died in 2024, and yet I hope he is having a major I-told-you-so moment about people blaming Pascal's bounds checking to be unneeded and making things slow.
To this day, FPC uses less ram than any C compiler, A good thing in today's increasingly ramless world and they've managed this with way less developers working on it than its C compiler equivalent, I can't even imagine what it would look like if they had the same amount of people working on it. C optimization tricks are hacks, the fact godbolt exists is proof that C is not meant to be optimizable at all, it is brute…
> […] C optimization tricks are hacks, the fact godbolt exists is proof that C is not meant to be optimizable at all, it is brute force witchcraft.
> At a certain point though, something's gotta give, the compiler can do guesswork, but it should do no more, if you have to add more metadata then so be it it's certainly less tedious than putting pragmas and _____ everywhere, some C code just looks like the writings of an insane person.
There is not even a single correct or factual statement in cited strings of words.
C optimisation is not «hacks» or «witchcraft»; it is built on decades of academic work and formal program analysis: optimisers use data-flow analysis over lattices and fixed points (abstract interpretation) and disciplined intermediate representations such as SSA, and there is academic work on proving that these transformations preserve semantics.
Modern C is also deliberately designed to permit optimisation under the as-if rule, with UB (undefined behaviour) and aliasing rules providing semantic latitude for aggressive transformations. The flip side is non-negotiable: compilers can't «guess» facts they can't prove, and many of the most valuable optimisations require guarantees about aliasing, alignment, loop independence, value ranges, and absence of UB that are often not derivable from arbitrary pointer-heavy C, especially under separate compilation.
That is why constructs such as «restrict», attributes and pragmas exist: they are not insanity, they are explicit semantic promises or cost-model steering that supply information the compiler otherwise must conservatively assume away.
«metadata instead» is the same trade-off in a different wrapper, unless you either trust it (changing the contract) or verify it (reintroducing the hard analysis problem).
Godbolt exists because these optimisations are systematic and comparable, not because optimisation is impossible.
Also, directives are not new, C-specific embarrassment: ALGOL-68 had «pragmats» (the direct ancestor of today’s «pragma» terminology), and PL/I had longstanding in-source compiler control directives, so this mechanism is decades older than and predates modern C tooling.