Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Neverflow: C macros that guard against buffer overflows

github.com

Post reply on HN
Print view View original

91–100 of 150 posts

Re: Neverflow: C macros that guard against buffer overflows

#91

Post by JohnFen »

adastra22 wrote: post #89
astrobe_ wrote: post #64

Earlier quoted context omitted.

> Note that C does have strong conventions, such as that strings are terminated by a zero byte Stated the same on HN earlier, but someone pointed out that literal strings are ASCIIZ.

One common trick in safer C libraries is to encode the length of the string one word prior to the beginning of the string. So "hello world" in memory would be 11 'h' 'e' 'l' 'l' 'o' ' ' 'w' 'o' 'r' 'l' 'd' '\0' ptr ^ C could be upgraded to do this in future versions, without too much backwards incompatibility.

> C could be upgraded to do this in future versions, without too much backwards incompatibility.

But I'd hope that doing that would always be optional. There are numerous situations where that would seriously get in the way.

Re: Neverflow: C macros that guard against buffer overflows

#92

Post by cornstalks »

This evaluates macro parameters multiple times, so if the parameters have side effects or evaluate inconsistently this won't work. For example:

    size_t SomeIndex() {
      static size_t example_index = 0;
      return example_index++ % 2;
    }

    int main() {
      NEW(int, arr, 1);
      // This buffer overflow is not detected:
      *AT(arr, SomeIndex()) = 42;
      return 0;
    }

Re: Neverflow: C macros that guard against buffer overflows

#93

Post by JohnFen »

coliveira wrote: post #31
epistasis wrote: post #17

Earlier quoted context omitted.

If one is ready to switch languages, then the clear winner is rust over C++, and I say that as someone who avoided diving into Rust for years because it seemed completely overhyped and with too much cryptic syntax. C still wins by far when writing libraries that will be used by lots of other people. Doesn't matter what language they are using, they will be able to add in a library written in C very easily. However, C…

People using C will not change to your language-du-jour, please stop.

Almost every dev I know who uses C (including myself) also uses other languages. Nobody should only have one tool in their toolbox.

Re: Neverflow: C macros that guard against buffer overflows

#94

Post by JohnFen »

mtlmtlmtlmtl wrote: post #51
lelanthran wrote: post #46

Earlier quoted context omitted.

> But now every caller in the future has to be aware of this possibility. Can you clarify: what possibility should you be aware off with malloc that you don't need to be aware of with calloc?

Calloc is the function originally intented to allocate arrays. Instead of accepting a number of bytes, it takes two unsigned integers(size_t): the number of array members, and the the size of each member. And it checks whether the result of multiplying them fits in a size_t. If not, it returns NULL, allocating nothing(and also sets errno, iirc). Then you can have your code detect it, crash or report an error, and avo…

calloc has its own set of gotchas, though. For instance, it may allocate a different amount of memory than you requested, and it comes with the overhead of zeroing out the allocated memory.

Neither of these may matter to you, but when they do, they really matter. So you still have to be thoughtful about using it. Not so different from how you have to be thoughtful about using malloc.

Re: Neverflow: C macros that guard against buffer overflows

#95

Post by kazinator »

The expansion of the AT macro seems a bit bloated:

  #define AT(NAME, IDX)                                         \
    ((typeof(&(*NAME)[0]))                                      \
    ((ASSERT(((size_t)IDX) * sizeof(*NAME)[0]
Some of this might be pushed into non-inlined run-time support function. That could be static and defined in the header, to keep it header-only, but ideally there would be a .c file so it's defined only once.

When you factor in the definition of ASSERT, and the ERRLOG macro that is using, it's a lot of cruft for just one array access.

Some compile-time options (via preprocessor macros) to control the bloat would be useful; e.g. a way of compiling it so that AT will just predictably crash, without a detailed error message with __FILE__ and __LINE__ and all. Basically just the check, with a branch to some code that calls abort() if it's out of bounds.

Re: Neverflow: C macros that guard against buffer overflows

#97

Post by humanrebar »

bfrog wrote: post #28
twic wrote: post #24

Earlier quoted context omitted.

The parent comment says "compiler tool chain", and i understand "tooling" here as meaning that. So, compiler, linker, assembler, etc. All the major C compilers are also C++ compilers, and none are (yet) Rust compilers, so out of the gate, C++ has similar availability to C.

If you are going on proprietary tool chains... most of those are moving to llvm which rust is based on. In theory any proprietary toolchain based on llvm could provide rustc given incentives to do so. If you are speaking to missing a rust compiler built on gcc, that seems to be an ongoing project with some momentum. Realistically the most widely used architectures are now supported by rustc through llvm... x86, arm,…

That's just the compilation toolchain. For better or worse, existing C projects have their whole workflows sitting on top of bespoke tools with the assumption that there is a C toolchain. And Rust projects assume cargo, etc. You're more or less doing a parallel rewrite in Rust to adopt Rust in an existing C project.

The Linux kernel already does extensive bespoke tooling and it's low level enough to skip cargo and such. It's rare to see that approach in Rust projects in the wild.

Re: Neverflow: C macros that guard against buffer overflows

#98

Post by CyberDildonics »

pjmlp wrote: post #96
CyberDildonics wrote: post #83

Earlier quoted context omitted.

If you did understood it, then explain it so I can understood it too.

Somehow doesn't seem worth my time.

So it was worth your time to reply twice, but not to explain anything?

Re: Neverflow: C macros that guard against buffer overflows

#99

Post by pjmlp »

CyberDildonics wrote: post #98
pjmlp wrote: post #96

Earlier quoted context omitted.

Somehow doesn't seem worth my time.

So it was worth your time to reply twice, but not to explain anything?

Yes, because I don't expect you to understand anyway and ELI5 would take a bit, much longer than these dumb comments.

Hint, someone else got it.

Re: Neverflow: C macros that guard against buffer overflows

#100

Post by pjmlp »

epistasis wrote: post #74
pjmlp wrote: post #56

Earlier quoted context omitted.

Unless we are talking about an obscure platform or some PIC CPU, a C++ compiler is available on the same box as the C compiler. Second, extern "C" exists. Third, in what concerns clang and MSVC, the C library is actually implemented in C++ with extern "C".

My single sentence may have been too concise, there are two concepts here: 1) the tool chain may or may not exist, and 2) bringing in that tool chain to the build system. Even if it's the "same" toolchain for compiling C++ as it is C, adding the complexity of an additional language to the build process, and the extra versioning headaches that C++ adds over C, is enough to kill library adoption. As I said originally,…

"To Save C, We Must Save ABI"

https://thephd.dev/to-save-c-we-must-save-abi-fixing-c-funct...

Post reply on HN