Live data from Hacker News

-fbounds-safety: Enforcing bounds safety for C

clang.llvm.org

81–90 of 129 posts

Re: -fbounds-safety: Enforcing bounds safety for C

#81
post #78

Amazing, this is a life saving feature for C developers. Apparently it's not complete yet? I will apply this to my code once the feature is included on LLVM and GCC. Would be nice if the annotations could also be applied to structure fields. struct bytes { size_t count; unsigned char * __counted_by(count) pointer; }; void work_with(struct bytes);

counted_by for struct fields actually is actually the part that afaik works today: https://embeddedor.com/blog/2024/06/18/how-to-use-the-new-co...

That's amazing. Thanks for that reference. If it's good enough for the kernel, then it's good enough for me to start using in my own projects.

It's really cool that the kernel is using this. The compiler must be generating simple bounds checking code with traps instead of crazy stuff involving magical C standard library functions. Perfect for freestanding nostdlib projects.

Re: -fbounds-safety: Enforcing bounds safety for C

#82
post #62
post #11

Earlier quoted context omitted.

It is called Solaris, and has this enabled since 2015 on SPARC. https://docs.oracle.com/en/operating-systems/solaris/oracle-...

Might as well not even talk about anything with the Oracular kiss of death.

Not everyone suffers from Oracle phobia.

Some of us actually do read licenses before using products.

Also the FAANG are hardly any better only because they spew cool marketing stuff like do no evil.

Re: -fbounds-safety: Enforcing bounds safety for C

#83
post #75
post #62

Earlier quoted context omitted.

Might as well not even talk about anything with the Oracular kiss of death.

Isn’t Illumos and OpenIndiana doing the same? I still remember someone at Sun commented they treated warnings as errors. This is how software should be developed.

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.

Re: -fbounds-safety: Enforcing bounds safety for C

#84
post #82
post #62

Earlier quoted context omitted.

Might as well not even talk about anything with the Oracular kiss of death.

Not everyone suffers from Oracle phobia. Some of us actually do read licenses before using products. Also the FAANG are hardly any better only because they spew cool marketing stuff like do no evil.

[deleted]

Re: -fbounds-safety: Enforcing bounds safety for C

#85
post #53
post #45

Earlier quoted context omitted.

There is GWPAsan that has lower overhead than asan but still is not super popular.

ASAN/LSAN is amazing. It absolutely monkey-hammers performance though.

> ASAN/LSAN is amazing. It absolutely monkey-hammers performance though.

It's not so bad; until the sanitisers arrived all we had was valgrind :-/

The sanitisers are about 10x to 50x faster than valgrind.

Re: -fbounds-safety: Enforcing bounds safety for C

#86
post #83
post #75

Earlier quoted context omitted.

Isn’t Illumos and OpenIndiana doing the same? I still remember someone at Sun commented they treated warnings as errors. This is how software should be developed.

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.

Re: -fbounds-safety: Enforcing bounds safety for C

#87

Earlier quoted context omitted.

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…

> 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. You are misremembering the various reports - the reports were not that 80%[1] of issues were due to memory errors, but more along the lines of 80% of exploits were due to memory errors. You could ha…

Yes. The problem is that most memory errors (out of bounds + use after free etc.) result in a vulnerability. Only a minority of the logic errors do.

For operating systems kernels, browsers etc, vulnerabilities have a much, much bigger impact than logic errors: vulnerabilities need to be fixed immediately, and released immediately. Most logic errors don't need to be fixed immediately (sure, it depends on the issue, and on the type of software.)

I would probably say "for memory unsafe languages, 80% of the _impact_ is due to memory vulnerabilities"

Re: -fbounds-safety: Enforcing bounds safety for C

#88
post #67

Niklaus 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 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.

Re: -fbounds-safety: Enforcing bounds safety for C

#89

Earlier quoted context omitted.

I don't understand this example: you're taking an address of local-scope stack object, storing it into a global list, and then use this address elsewhere in the code, possibly at different time-point, to manipulate with the object? I am obviously missing something because this cannot work unless this object lives on the stack of main().

The best example I know of off the top of my head is wait_event() in Linux. So long as the thread is guaranteed not to exit while blocked, you know its stack, and therefore the object allocated on it, must continue to exist. So, as long as there is no way to wake the thread except by kicking that object, the memory backing it is guaranteed to continue to exist until that object is kicked. You do have to somehow seria…

Ok, I see, thanks for the example. Is this technique used to avoid the potential runtime performance cost because one would otherwise need to keep that object elsewhere/heap and not on a stack? Or is the problem definition something else?

Re: -fbounds-safety: Enforcing bounds safety for C

#90
post #86
post #83

Earlier 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.

It's good info, and I wouldn't rush a migration off of SPARC systems if I was already using them, but slow death is still death. It was already worrying that workstations were killed off by Sun before the Oracle acquisition; it seems quite clear that no one has been serious about spreading adoption of the architecture for more than two decades now.
Post reply on HN