Hacker ApprovedDepartments

Clang -fbounds-safety

Hacker Approved

Compiler extension in Developer tools

Clang extension that adds bounds checking to C, catching out-of-bounds memory access that causes many security bugs. Main caveat: it needs annotations and protects only bounds.

Clang extension that adds bounds checking to C, catching out-of-bounds memory access that causes many security bugs. Main caveat: it needs annotations and protects only bounds.

16 people gave an opinion

recommend it
13
criticize it
3
approval share
81%
Each figure is one person. RecommendsCriticizes

Recommended in 6 of 13 months

  1. November 2025: recommended
  2. December 2025: not recommended
  3. January 2026: not recommended
  4. February 2026: recommended
  5. March 2026: not recommended
  6. April 2026: not recommended
  7. May 2026: recommended
  8. June 2026: recommended
  9. July 2026: recommended
  10. August 2026: recommended
  11. September 2026: not recommended
  12. October 2026: not recommended
  13. November 2026: not recommended (month in progress)

Why it carries the badge

  • 13 people recommend itNeeds 10 or more, met.
  • 4.3 recommenders for every criticNeeds 2 to 1 or better, met.
  • Recommended in 6 of 13 monthsNeeds 4 or more, met.

The same three rules apply to every product, and the badge can’t be bought. How the badge works

What people say about it

The reasons people give, with the number of comments that give each one. Open a reason to read what they said.

Why people recommend it

Each mark is one comment

  • Stops out-of-bounds memory access

    “Very cool. I always wondered why there isn't something like this in GCC/LLVM, it would obviously solve uncountable of security issues.”

    Comment from 19 Feb 2026 in “-fbounds-safety: Enforcing bounds safety for C”

    “this is amazing, counter to what most ppl think, majority of memory bugs are from out of bounds access”

    Comment from 19 Feb 2026 in “-fbounds-safety: Enforcing bounds safety for C”

    “life saving feature for C developers”

    Comment from 19 Feb 2026 in “-fbounds-safety: Enforcing bounds safety for C”
  • Used in kernel and WebKit

    “If it's good enough for the kernel, then it's good enough for me to start using in my own projects.”

    Comment from 19 Feb 2026 in “-fbounds-safety: Enforcing bounds safety for C”

    “The WebKit folks have apparently been very successful with the annotations approach”

    Comment from 19 Feb 2026 in “-fbounds-safety: Enforcing bounds safety for C”
  • Incremental adoption with ABI compatibility

    “legacy C code can/should absolutely use things like clang's -fbounds-safety”

    Comment from 13 Jun 2026 in “Swift at Apple: Migrating the TrueType Hinting Interpreter”

    “It offers ABI compatibility and incremental adoption.”

    Comment from 14 Aug 2026 in “I want extern "fil-C"”
  • Works as a stand-in slice type

    “this is a minor inconvenience for having an otherwise working span type in C”

    Comment from 19 Feb 2026 in “-fbounds-safety: Enforcing bounds safety for C”

    “serves as a decent stop-gap to a proper slice type”

    Comment from 26 Jul 2026 in “Memory Safety Absolutists”

What people said

17 of the 19 comments that mention it, newest first. Each links to the original comment.

“strictly less safe than either Fil-C or Rust since it only protects bounds”

MixedComment from 14 Aug 2026 in “I want extern "fil-C"”

“It offers ABI compatibility and incremental adoption.”

RecommendsComment from 14 Aug 2026 in “I want extern "fil-C"”

“serves as a decent stop-gap to a proper slice type”

RecommendsComment from 26 Jul 2026 in “Memory Safety Absolutists”

“legacy C code can/should absolutely use things like clang's -fbounds-safety”

RecommendsComment from 13 Jun 2026 in “Swift at Apple: Migrating the TrueType Hinting Interpreter”

“they've been huge proponents of fbounds check in clang which can achieve a small portion (but important!) of what memory safe languages can do”

RecommendsComment from 15 May 2026 in “First public macOS kernel memory corruption exploit on Apple M5”

“The WebKit folks have apparently been very successful with the annotations approach”

RecommendsComment from 19 Feb 2026 in “-fbounds-safety: Enforcing bounds safety for C”

“If it's good enough for the kernel, then it's good enough for me to start using in my own projects.”

RecommendsComment from 19 Feb 2026 in “-fbounds-safety: Enforcing bounds safety for C”

“life saving feature for C developers”

RecommendsComment from 19 Feb 2026 in “-fbounds-safety: Enforcing bounds safety for C”

“the general stack variable thing is going to break too much real world code”

MixedComment from 19 Feb 2026 in “-fbounds-safety: Enforcing bounds safety for C”

“this is a minor inconvenience for having an otherwise working span type in C”

MixedComment from 19 Feb 2026 in “-fbounds-safety: Enforcing bounds safety for C”

“it's basically impossible.”

MixedComment from 19 Feb 2026 in “-fbounds-safety: Enforcing bounds safety for C”

“The annotation requirement means this won't just slot into existing codebases”

MixedComment from 19 Feb 2026 in “-fbounds-safety: Enforcing bounds safety for C”

“Very cool. I always wondered why there isn't something like this in GCC/LLVM, it would obviously solve uncountable of security issues.”

RecommendsComment from 19 Feb 2026 in “-fbounds-safety: Enforcing bounds safety for C”

“this is amazing, counter to what most ppl think, majority of memory bugs are from out of bounds access”

RecommendsComment from 19 Feb 2026 in “-fbounds-safety: Enforcing bounds safety for C”

“You should tell the LLVM folks, I guess they didn't know about this.”

CriticizesComment from 19 Feb 2026 in “-fbounds-safety: Enforcing bounds safety for C”

“just use C++ and 5 lines of standard, portable, no-weird-annotations code instead”

CriticizesComment from 19 Feb 2026 in “-fbounds-safety: Enforcing bounds safety for C”

“-fbounds-safety is awesome!”

RecommendsComment from 7 Nov 2025 in “A Note on Fil-C”

Counts come from 1,795,640 Hacker News comments, November 2025 to November 2026. How we count. Report a mistake.