[HN Gopher] -fbounds-safety: Enforcing bounds safety for C
___________________________________________________________________
-fbounds-safety: Enforcing bounds safety for C
Author : thefilmore
Score : 101 points
Date : 2026-02-16 14:05 UTC (3 days ago)
(HTM) web link (clang.llvm.org)
(TXT) w3m dump (clang.llvm.org)
| musicale wrote:
| I want an OS distro where all C code is compiled this way.
|
| OpenBSD maybe? or a fork of CheriBSD?
|
| macOS clang has supported -fbounds-safety for a while, but I"m
| not sure how extensively it is used.
| 1over137 wrote:
| >I want an OS distro where all C code is compiled this way.
|
| You first have to modify "all C code". It's not just a set and
| forget compiler flag.
| wyldfire wrote:
| You need to annotate your program with indications of what
| variable tracks the size of the allocation. So, sure, but first
| work on the packages in the distro.
|
| Note that corresponding checks for C++ library containers can
| be enabled without modifying the source. Google measured some
| very small overhead (< 0.5% IIRC) so they turned it on in
| production. But I'd expect an OS distro to be mostly C.
|
| [1] https://libcxx.llvm.org/Hardening.html
| bombcar wrote:
| Get gentoo, add this to CFLAGS and start fixing everything that
| breaks. Become a hero.
| pezgrande wrote:
| does any distro uses clang? I thought all linux kernels were
| compiled using gcc.
| zmodem wrote:
| Not a Linux distro, but FreeBSD uses Clang.
|
| And Android uses Clang for its Linux kernel.
|
| -fbounds-safety is not yet available in upstream Clang
| though:
|
| > NOTE: This is a design document and the feature is not
| available for users yet.
| honktime wrote:
| Chimera does, it also has a FreeBSD userland AFAIU.
|
| https://chimera-linux.org/
| yjftsjthsd-h wrote:
| https://www.kernel.org/doc/html/latest/kbuild/llvm.html
|
| > The Linux kernel has always traditionally been compiled
| with GNU toolchains such as GCC and binutils. Ongoing work
| has allowed for Clang and LLVM utilities to be used as viable
| substitutes. Distributions such as Android, ChromeOS,
| OpenMandriva, and Chimera Linux use Clang built kernels.
| Google's and Meta's datacenter fleets also run kernels built
| with Clang.
| pjmlp wrote:
| It is called Solaris, and has this enabled since 2015 on SPARC.
|
| https://docs.oracle.com/en/operating-systems/solaris/oracle-...
| salawat wrote:
| Might as well not even talk about anything with the Oracular
| kiss of death.
| rbanffy wrote:
| 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.
| kbolino wrote:
| 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.
| pjmlp wrote:
| 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.
| kbolino wrote:
| 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.
| pjmlp wrote:
| 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.
| prussian wrote:
| Fedora and its kernels are built with GCC's _FORTIFY_SOURCE and
| I've seen modules crash for out of bounds reads.
| dezgeg wrote:
| _FORTIFY_SOURCE is way smaller in scope (as in, closes less
| vulnerabilities) than -fbounds-safety.
| groundzeros2015 wrote:
| What are you hoping it will achieve?
| irishcoffee wrote:
| 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.
| random_mutex wrote:
| A panic in Rust is easier to diagnose and fix than some
| error or grabage data that was caused by an out of bounds
| access in some random place in the call stack
| hypeatei wrote:
| 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?
| groundzeros2015 wrote:
| I think the point is memory bugs are only one (small)
| subset of bugs.
| Abstract_Typist wrote:
| 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...
| groundzeros2015 wrote:
| Security bugs - and not bad security processes, are a
| small subset of bugs.
| wat10000 wrote:
| 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.
| groundzeros2015 wrote:
| Why can it be exploited? I've configured my OS so my
| process is isolated to the resources it needs.
| kgeist wrote:
| Maybe this:
|
| https://fil-c.org/pizlix
|
| >Pizlix is LFS (Linux From Scratch) 12.2 with some added
| components, where userland is compiled with Fil-C. This means
| you get the most memory safe Linux-like OS currently available.
|
| The author, @pizlonator, is active on HN.
| functionmouse wrote:
| hot dang that's neato. shame about the name, though.
| hsaliak wrote:
| https://github.com/hsaliak/filc-bazel-template i created this
| recently to make it super easy to get started with fil-c
| projects. If you find it daunting to get started with the
| setup in the core distribution and want a 3-4 step approach
| to building a fil-c enabled binary, then try this.
| nananana9 wrote:
| template <typename T> struct Slice { T* data =
| nullptr; size_t size = nullptr; T&
| operator[](size_t index) { if (index >= size)
| crash_the_program(); return data[index]; }
| };
|
| If you're considering this extension, just use C++ and 5 lines of
| standard, portable, no-weird-annotations code instead.
| baq wrote:
| and if you write directly in assembly you don't even need a C++
| compiler
| nananana9 wrote:
| That's an objectively correct statement, but I don't see how
| it makes sense as a response to my comment, as I'm advocating
| to use the more advanced feature-rich tool over the compiler-
| specific-hacks one.
| zephen wrote:
| > I don't see how it makes sense as a response to my
| comment
|
| Your comment started out with "just."
|
| As if there are never any compelling reasons to want to
| make existing C code better.
|
| But instead of taking that as an opportunity to reflect on
| when various tools might be appropriate,
|
| > as I'm advocating to use the more advanced feature-rich
| tool over the compiler-specific-hacks one.
|
| You've simply doubled down.
| yjftsjthsd-h wrote:
| If you're advocating switching languages, then there's no
| reason to stop at C++. It's more common to propose just
| converting the universe to Rust, but assembly _also_ enjoys
| the possibility of being fairly easy to drop in on an
| existing C project.
| pjmlp wrote:
| Even better, starting with C++26, and considered to be done
| with DR for previous versions, hardned runtimes now have a
| portable way to be configured across compilers, instead of each
| having their own approach.
|
| However, you still need something like -fbounds-safety in C++,
| due to the copy-paste compatibility with C, and too many people
| writing Orthodox C++, C with Classes, Better C, kind of code,
| that we cannot get rid of.
| nananana9 wrote:
| I'm sure std::span is great, but I like mine better :)
|
| I find it a bit hard to justify using the STL when a single
| <unordered_map> include costs 250ms compile time per compile
| unit.
|
| The fact that I don't have to step through this in the
| debugger is also a bonus: template <size_t
| _Offset, size_t _Count = dynamic_extent> [[nodiscard]]
| _LIBCPP_HIDE_FROM_ABI constexpr auto subspan() const noexcept
| -> span<element_type, _Count != dynamic_extent ? _Count :
| _Extent - _Offset> { static_assert(_Offset <=
| _Extent, "span<T, N>::subspan<Offset, Count>(): Offset out of
| range"); static_assert(_Count == dynamic_extent ||
| _Count <= _Extent - _Offset, "span<T,
| N>::subspan<Offset, Count>(): Offset + Count out of range");
| using _ReturnType = span<element_type, _Count !=
| dynamic_extent ? _Count : _Extent - _Offset>; return
| _ReturnType{data() + _Offset, _Count == dynamic_extent ?
| size() - _Offset : _Count}; }
| pjmlp wrote:
| Only if not able to do _import std_ , or pre-compiled
| headers, and not using modern IDEs with "just my code"
| filters.
|
| As someone that enjoys C++ since 1993, alongside other
| ecosystems, many pain points on using C++ complaints are
| self inflicted, by avoiding using modern tools.
|
| Heck, C++ had nice .NET and Java alike frameworks, with
| bounds checking even, before those two systems came to
| exist, and nowadays all those frameworks are mostly gone
| with exception of Qt and C++ Builder ones, due to bias.
| zmodem wrote:
| The extension is for hardening legacy C code without breaking
| ABI.
| wat10000 wrote:
| You should tell the LLVM folks, I guess they didn't know about
| this.
| uecker wrote:
| Or just do it in C. #define span(T) struct
| span_##T { size_t len; T *data; } #define span_access(T,
| x, i) (*({ \ span(T) *_v = (x);
| \ auto _i = (i); \
| if (((size_t)_i) >= _v->len) abort(); \
| &_v->data[_i]; \ }))
|
| https://godbolt.org/z/TvxseshGc
| nananana9 wrote:
| Still requires a gcc/clang specific extension (although this
| one I'd be very happy to see standardized)
| uecker wrote:
| Only statement expressions, but one can also implement this
| without them.
| fuhsnn wrote:
| The fact that pointer types can't be used with this pattern
| without typedef still seems kinda primitive to me.
| uecker wrote:
| You can use pointer types by using a typedef first, but I
| agree this not nice (I hope we will fix this in future C).
| But then, I think this is a minor inconvenience for having
| an otherwise working span type in C.
| osmsucks wrote:
| size_t size = nullptr;
|
| wat
| taminka wrote:
| this is amazing, counter to what most ppl think, majority of
| memory bugs are from out of bounds access, not stuff like
| forgetting to free a pointer or some such
| Retr0id wrote:
| I think UAFs are more common in mature software
| q3k wrote:
| Or type confusion bugs, or any other stuff that stems from
| complex logic having complex bugs.
|
| Boundary checking for array indexing is table stakes.
| michh wrote:
| table stakes, but people still mess up on it constantly.
| The "yeah, but that's only a problem if you're an idiot"
| approach to this kind of thing hasn't served us very well
| so it's good to see something actually being done.
|
| Trains shouldn't collide if the driver is correctly
| observing the signals, that's table stakes too. But rather
| than exclusively focussing on improving track to reduce
| derailments we also install train protection systems that
| automatically intervene when the driver _does_ miss a
| signal. Cause that happens a lot more than a derailment.
| Even though "pay attention, see red signal? stop!" is
| conceptually super easy.
| q3k wrote:
| I'm not saying it's not important, it is. I just don't
| believe that '[the] majority of memory bugs are from out
| of bounds access'. That was maybe true 20 years ago, when
| an unbounded strcpy to an unprotected return pointer on
| the stack was super common and exploiting this kind of
| vulnerabilities what most vulndev was.
|
| This brings C one tiny step closer to the state of the
| art, which is commendable, but I don't believe codebases
| which start using this will reduce their published
| vulnerability count significantly. Making use of this
| requires effort and diligence, and I believe most
| codebases that can expend such effort already have a
| pretty good security track record.
| vlovich123 wrote:
| The majority of security vulnerabilities in languages
| like C that aren't memory safe are due to memory safety
| issues like UAF, buffer overflows etc etc. I don't think
| I've seen finer grained research that tries to break it
| out by class of memory safety issue. The data is
| something like 80% of reported vulnerabilities in code
| written in these languages are due to memory safety
| issues. This doesn't mean there aren't other issues. It
| just means that it's the cheapest exploit to search for
| when you are trying to break into a C/C++ service.
|
| And in terms of how easy it is to convert a memory safety
| issue into an exploit, it's not meaningfully much harder.
| The harder pieces are when sandboxing comes into play so
| that for example exploiting V8 doesn't give you arbitrary
| broader access if the compromised process is itself
| sandboxed.
| random_mutex wrote:
| There is use after free
| eecc wrote:
| Majority. Parent said majority
| IshKebab wrote:
| Exactly. Use after free is common enough that you can't
| just assert that out-of-bounds is the majority without
| evidence.
| taminka wrote:
| 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...
| woodruffw wrote:
| "Majority" could mean a few things; I wouldn't be surprised if
| the majority of discovered memory bugs are spatial, but I'd
| expect the majority of widely _exploited_ memory bugs to be
| temporal (or pseudo-temporal, like type confusions).
| Night_Thastus wrote:
| Personally, as someone in C and C++ for the last few years,
| memory access is almost never the root bug. It's almost always
| logic errors. Not accounting for all paths, not handling edge
| cases, not being able to handle certain combinations of user or
| file input, etc.
|
| Occasionally an out-of-bounds access pops up, but they're
| generally so blindingly obvious and easy to fix that it's never
| been the slow part of bug fixing.
| lelanthran wrote:
| 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.
| vlovich123 wrote:
| 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 code was super simple OR you didn't test
| it thoroughly enough against malicious/unexpected inputs OR
| you never connected the code to untrusted I/O.
|
| Keep in mind the data for this comes from popular projects
| that have enough attention to warrant active exploit
| research by a wide population. This is different from a
| project you wrote that doesn't have the same level of
| attention.
| lelanthran wrote:
| > 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 have 1000 bugs, with 10 of them being
| vulnerabilities, and 8 of those 10 being due to memory
| errors, and that would still be in line with the reports.
|
| > As for why your experience may be different, my hunch
| is that either your code was super simple OR you didn't
| test it thoroughly enough against malicious/unexpected
| inputs OR you never connected the code to untrusted I/O.
|
| Payments processing, telecoms and munitions control
| software.
|
| Of those, your explanation only applies to Telecoms;
| payments processing (EMV) was basically a constant stream
| of daily attacks, while munitions are live, in the field,
| with real explosives. We would've noticed _any_ bugs, not
| just memory error bugs with the munitions one.
|
| --------------------
|
| [1] The number wasn't 80% IIRC, more like 70%?
| thomasmg wrote:
| 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"
| taminka wrote:
| logic errors aren't memory errors, unless you have some
| complex piece of logic for deallocating resources, which,
| yeah, is always tricky and should just generally be avoided
| worldsavior wrote:
| Very cool. I always wondered why there isn't something like this
| in GCC/LLVM, it would obviously solve uncountable of security
| issues.
| ndiddy wrote:
| Has any progress been made on this? I remember seeing this
| proposal 3 or 4 years ago but it looks like it still hasn't been
| implemented. It's a shame because it seems like a useful feature.
| It looks like Microsoft has something similar
| (https://learn.microsoft.com/en-us/cpp/code-quality/understan...)
| but it would be nice to have something that worked on other
| platforms.
| Someone wrote:
| https://discourse.llvm.org/t/the-preview-of-fbounds-
| safety-i...:
|
| _"-fbounds-safety is a language extension to enforce a strong
| bounds safety guarantee for C. Here is our original RFC.
|
| We are thrilled to announce that the preview implementation of
| -fbounds-safety is publicly available at this fork of llvm-
| project. Please note that we are still actively working on
| incrementally open-sourcing this feature in the llvm.org/llvm-
| project . To date, we have landed only a small subset of our
| implementation, and the feature is not yet available for use
| there. However, the preview does contain the working feature.
| Here is a quick instruction on how to adopt it."_
|
| "This fork" is https://github.com/swiftlang/llvm-
| project/tree/stable/202407..., Apple's fork of LLVM. That
| branch is from a year ago.
|
| I don't know whether there's a newer publicly available
| version.
|
| There is a GSoC 2026 opportunity on upstreaming this into
| mainline LLVM
| (https://discourse.llvm.org/t/gsoc-2026-participating-in-
| upst...)
| groos wrote:
| Microsoft's SAL annotations are meant to inform the static
| analyzer how the parameters are meant to be used so any
| violations of the contract can be diagnosed at compile time.
| The LLVM proposal is different in that it is checked at run
| time and will stop your program before it makes an out of
| bounds access. Static analyzers can obviously use the
| information in the type to help diagnose a subset of such
| problems at compile time.
| mrpippy wrote:
| Apple is shipping code built with this, and is supporting it
| for developers to use (see
| https://developer.apple.com/documentation/xcode/enabling-
| enh...)
| cranberryturkey wrote:
| 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 <0.5%
| overhead is compelling precisely because it required zero source
| changes.
|
| 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 catches
| in practice vs. what ASAN already finds in CI.
| favorited wrote:
| 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
| manbash wrote:
| Exciting! It doesn't imply that we should now sprinkle the new
| annotations everywhere. We still should keep working with proper
| iterators and robust data structures, and those would need to add
| such annotations.
| hoyhoy wrote:
| Xcode (AppleClang) has had -fbounds-safety for a while now. What
| is the delay getting this into merged into LLVM?
| jcalvinowens wrote:
| > As local variables are typically hidden from the ABI, this
| approach has a marginal impact on it.
|
| I'm skeptical this is workable... it's pretty common in systems
| code to take the address of a local variable and pass it
| somewhere. Many event libraries implement waiting for an event
| that way: push a pointer to a futex on the stack to a global
| list, and block on it.
|
| They address it explicitly later:
|
| > Although simply modifying types of a local variable doesn't
| normally impact the ABI, taking the address of such a modified
| type could create a pointer type that has an ABI mismatch
|
| That breaks a lot of stuff.
|
| The explicit annotations seem like they could have real value for
| libraries, especially since they can be ifdef'd away. But the
| general stack variable thing is going to break too much real
| world code.
| rbanffy wrote:
| I would imagine variables that are passed to functions would be
| considered ABI-visible. If the compiler is smart enough, it can
| keep the pointer wide when it's passed to a function that's
| also being compiled and act accordingly on the other side, but
| that worries me because this new meaning of "pointer" is
| propagating to parts of the code that might not necessarily
| agree with it.
| menaerus wrote:
| 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().
| jandrese wrote:
| Yep, it's a straight up error in C to return the address of a
| local variable from a function outside of main. Valgrind will
| flag this as use of an uninitialized value.
|
| The problem is that as long as it's something where the
| calling function checks it immediately after the function
| exits and never looks again (something like an error code or
| choosing a code path based on the result) they often get away
| with it, especially in single threaded code.
|
| I'm running into this at this very moment as I'm trying to
| make my application run cleanly, but some of the libraries
| are chock full of this pattern. One big offender is the Unix
| port of Microsoft's ODBC library, at least the Postgre
| integration piece.
|
| I also blame the Unix standard library for almost having this
| pattern but not quite. Functions that return some kind of
| internal state that the programmer is told not to touch.
| Later they had to add a bunch of _r variants that were thread
| safe. The standard library functions don't actually have this
| flaw due to how they define their variables, but from the
| outside it looks like they do. It makes beginning programmers
| think that is how the functions should work and write their
| code in a similar manner.
| jcalvinowens wrote:
| > Yep, it's a straight up error in C to return the address
| of a local variable from a function
|
| Sure, that's true, but nobody is suggesting returning the
| address of a local variable anywhere in this thread.
|
| I'm describing putting a pointer to a local variable in a
| global data structure, which is safe so long as the
| function doing it is somehow guaranteed not to return until
| the pointer is removed from the global data structure.
| jcalvinowens wrote:
| 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
| serialize the global data structure lookup (e.g. lock
| /dequeue/unlock/kick), if multiple threads can find and kick
| the object concurrently that's unsafe (the thread might exit
| between the first and subsequent kicks).
|
| Generally that's true, even in pthread userspace: while there
| are some obvious artificial counterexamples one can
| construct, real world code very rarely does things like that.
| menaerus wrote:
| 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?
| jcalvinowens wrote:
| 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.
| tandr wrote:
| 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.
| nmz wrote:
| 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.
| diath wrote:
| 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
| matheusmoreira wrote:
| 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);
| zokier wrote:
| 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...
| matheusmoreira wrote:
| 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.
| uecker wrote:
| Clang has this and upcoming GCC will also have this:
| https://godbolt.org/z/KETrPEnT1
| matheusmoreira wrote:
| This is awesome!!
| kazinator wrote:
| > _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/
___________________________________________________________________
(page generated 2026-02-19 23:02 UTC)