Live data from Hacker News

-fbounds-safety: Enforcing bounds safety for C

clang.llvm.org

91–100 of 129 posts

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

#91

Earlier quoted context omitted.

The internet didn't go down and you're mischaracterizing it as a parsing issue when the list would've exceeded memory allocation limits. They didn't hardcode a fallback config for that case. What memory safety promise did Rust fail there exactly?

I think the point is memory bugs are only one (small) subset of bugs.

The conventional wisdom is ~70% of serious security bugs are memory safety issues.

https://www.cisa.gov/sites/default/files/2023-12/CSAC_TAC_Re...

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

#92

Earlier quoted context omitted.

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?

It's just mechanically simpler that way. If the wakee thread dynamically allocated the object, it would have to free it after being woken: may as well let the compiler do that automatically for us.

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

#93
> To tackle this issue, the model incorporates the concept of a “wide pointer” (a.k.a. fat pointer) – a larger pointer that carries bounds information alongside the pointer value.

Bounds checking with fat pointers existed as a set of patches for GCC in the early 2000's. (C front end only).

https://sourceforge.net/projects/boundschecking/

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

#95
post #28

Earlier quoted context omitted.

Majority. Parent said majority

Exactly. Use after free is common enough that you can't just assert that out-of-bounds is the majority without evidence.

actually you may be right, according to project zero by google [1], ~50% is use after free and only ~20% for out of bounds errors, however, this is for errors that resulted in major exploits, i'm not sure what the overall data is

[1] https://projectzero.google/2022/04/the-more-you-know-more-yo...

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

#96

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);

Clang has this and upcoming GCC will also have this: https://godbolt.org/z/KETrPEnT1

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

#97

The real question is adoption friction. The annotation requirement means this won't just slot into existing codebases — someone has to go through and mark up every buffer relationship. Google turning on libcxx hardening in production with The incremental path matters more than the theoretical coverage. I'd love to see benchmarks on a real project — how many annotations per KLOC, and what % of OOB bugs it actually cat…

The WebKit folks have apparently been very successful with the annotations approach[0]. It's a shame that a few of the loudest folks in WG21 have decided that C++ already has the exact right number of viral annotations already, and that the language couldn't possibly survive this approach being standardized.

[0]https://www.youtube.com/watch?v=RLw13wLM5Ko

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

#98

Earlier quoted context omitted.

I think the point is memory bugs are only one (small) subset of bugs.

The conventional wisdom is ~70% of serious security bugs are memory safety issues. https://www.cisa.gov/sites/default/files/2023-12/CSAC_TAC_Re...

Security bugs - and not bad security processes, are a small subset of bugs.

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

#99

Earlier quoted context omitted.

The internet went down because cloudflare used a bad config... a config parsed by a rust app. One of these days the witch hunt against C will go away.

A service going down is a million times better than being exploited by an attacker. If this is a witch hunt then C is an actual witch.

Why can it be exploited? I’ve configured my OS so my process is isolated to the resources it needs.

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

#100
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.

There's a blog post from Google about this topic as well where they found that inserting bound checking into standard library functions (in this case C++) had a mere 0.3% negative performance impact on their services: https://security.googleblog.com/2024/11/retrofitting-spatial...

For people using Clang you can read more about libc++ hardening at https://libcxx.llvm.org/Hardening.html

Post reply on HN