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

21–30 of 150 posts

Re: Neverflow: C macros that guard against buffer overflows

#21

Post by humanrebar »

epistasis wrote: post #17
inetknght wrote: post #12

Why use C and keep reinventing things that C++ provides?

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…

Availability of C++ tooling is much, much closer to availability of C tooling (often it's the same tool!) compared to Rust. Adopting Rust isn't the same category of conversion at all.

For new side projects, pick what you want to use of course. But for existing codebases and projects that aspire to have maximum impact, I recommend fully considering tradeoffs instead of thinking in terms of "clear winners".

Re: Neverflow: C macros that guard against buffer overflows

#22

Post by insanitybit »

humanrebar wrote: post #21
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…

Availability of C++ tooling is much, much closer to availability of C tooling (often it's the same tool!) compared to Rust. Adopting Rust isn't the same category of conversion at all. For new side projects, pick what you want to use of course. But for existing codebases and projects that aspire to have maximum impact, I recommend fully considering tradeoffs instead of thinking in terms of "clear winners".

> Availability of C++ tooling is much, much closer to availability of C tooling (often it's the same tool!) compared to Rust. Adopting Rust isn't the same category of conversion at all.

Which tooling? Just curious, asking entirely in good faith. My recollection is that the majority of tooling I was using with C++ worked with Rust - debuggers, profilers, and sanitizers being the main tools. Although I find that I use them much less frequently since I don't find debuggers as useful for the types of bugs I have these days, and sanitizers are only useful if you have unsafe, and profilers are cool but usually I just write benchmarks using a crate and then iterate from there.

Re: Neverflow: C macros that guard against buffer overflows

#23

Post by [deleted] »

frabert wrote: post #6
heylemao wrote: post #3

Earlier quoted context omitted.

Yeap, that's the whole point of it

Huh I misinterpreted the error messages in the example, I thought those were compiler output. This is quite cool then. EDIT: although, it seems like this looses much of its power once you start passing these buffers around to functions that do not use these macros.

[deleted]

Re: Neverflow: C macros that guard against buffer overflows

#24

Post by twic »

insanitybit wrote: post #22
humanrebar wrote: post #21

Earlier quoted context omitted.

Availability of C++ tooling is much, much closer to availability of C tooling (often it's the same tool!) compared to Rust. Adopting Rust isn't the same category of conversion at all. For new side projects, pick what you want to use of course. But for existing codebases and projects that aspire to have maximum impact, I recommend fully considering tradeoffs instead of thinking in terms of "clear winners".

> Availability of C++ tooling is much, much closer to availability of C tooling (often it's the same tool!) compared to Rust. Adopting Rust isn't the same category of conversion at all. Which tooling? Just curious, asking entirely in good faith. My recollection is that the majority of tooling I was using with C++ worked with Rust - debuggers, profilers, and sanitizers being the main tools. Although I find that I use…

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.

Re: Neverflow: C macros that guard against buffer overflows

#25

Post by augustk »

Even without array bounds checking, a bit of discipline and smart conventions will go a long way of reducing errors:

1. Define a macro function for retrieving the length of an array:

  #define LEN(arr) (sizeof (arr) / sizeof (arr)[0])
2. Don't introduce macro constants for array lengths; hard code the length in the declaration and use LEN to retrieve it. Example:

  int a[100];
  ...
  for (i = 0; i
3. Define a macro function for dynamic array allocation:

  #define NEW_ARRAY(ptr, n) \
     (ptr) = malloc((n) * sizeof (ptr)[0]); \
     if ((ptr) == NULL) { \
        fprintf(stderr, "Memory allocation failed: %s\n", strerror(errno)); \
        exit(EXIT_FAILURE); \
     }
4. When you create a function with an array argument, also add an argument for the array length.

5. Use a convention for naming the length of array pointer targets, for instance by adding the suffix `Len'. Example:

  int *b, bLen = 100;
  ...
  NEW_ARRAY(b, bLen);  /* nice to know that b and bLen belong together */
  ...
  SomeFunction(b, bLen, ...);
  ...
  for (i = 0; i
6. Define your own safe wrappers around unsafe standard library functions or use someone else's code that does that.

Re: Neverflow: C macros that guard against buffer overflows

#26

Post by ChrisRR »

augustk wrote: post #25

Even without array bounds checking, a bit of discipline and smart conventions will go a long way of reducing errors: 1. Define a macro function for retrieving the length of an array: #define LEN(arr) (sizeof (arr) / sizeof (arr)[0]) 2. Don't introduce macro constants for array lengths; hard code the length in the declaration and use LEN to retrieve it. Example: int a[100]; ... for (i = 0; i 3. Define a macro function…

The issue with 1 is that it only works until you pass an array into a function by pointer, then the macro no longer works.

In my experience it's most likely that a function will write past the bounds of a buffer that's been passed as an argument. In that case, make sure the size of array is always included as an argument as you said in 4.

Re: Neverflow: C macros that guard against buffer overflows

#27

Post by ChrisRR »

inetknght wrote: post #12

Why use C and keep reinventing things that C++ provides?

For me the issue is that using C++ brings every single feature in with it. It's very easy to hire developers and they know the entirety of the C language, but using C++ has every feature you could ever want and multiple ways of achieving the same thing.

It makes writing (and hiring) a low-level project in C++ a much more complex task. It may have benefits, it may not. But C++ is so huge that it's difficult to judge whether it would offer an advantage.

And then there's the minefield of tooling in embedded development...

Re: Neverflow: C macros that guard against buffer overflows

#28

Post by bfrog »

twic wrote: post #24
insanitybit wrote: post #22

Earlier quoted context omitted.

> Availability of C++ tooling is much, much closer to availability of C tooling (often it's the same tool!) compared to Rust. Adopting Rust isn't the same category of conversion at all. Which tooling? Just curious, asking entirely in good faith. My recollection is that the majority of tooling I was using with C++ worked with Rust - debuggers, profilers, and sanitizers being the main tools. Although I find that I use…

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, riscv, and even to some extent xtensa now.

Power, arc, mips, sparc, and some others aren't too far away if someone cared enough.

If Linux can support Rust, I'd think that's a good sign most project can use Rust.

Re: Neverflow: C macros that guard against buffer overflows

#29

Post by kllrnohj »

epistasis wrote: post #17
inetknght wrote: post #12

Why use C and keep reinventing things that C++ provides?

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…

Exporting a stable C ABI/API in no way requires writing the implementation in C. See Android's NDK for a rather widely deployed example. All the APIs are C, yet none of the implementations are C. Same thing works great in Rust, too. You can trivially export C from a Rust implementation.

Re: Neverflow: C macros that guard against buffer overflows

#30

Post by teo_zero »

frabert wrote: post #6
heylemao wrote: post #3

Earlier quoted context omitted.

Yeap, that's the whole point of it

Huh I misinterpreted the error messages in the example, I thought those were compiler output. This is quite cool then. EDIT: although, it seems like this looses much of its power once you start passing these buffers around to functions that do not use these macros.

> this looses much of its power once you start passing these buffers around to functions that do not use these macros.

Alas it's even worse: once you pass buffers around to functions, you can't use these macros!

Post reply on HN