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

31–40 of 150 posts

Re: Neverflow: C macros that guard against buffer overflows

#31

Post by coliveira »

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…

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

Re: Neverflow: C macros that guard against buffer overflows

#32

Post by hgsgm »

ChrisRR wrote: post #27
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 w…

Knowing every feature of C means they have to learn custom patterns on top of the C to make things work, and that almost always means horrific unhygienic macros.

Re: Neverflow: C macros that guard against buffer overflows

#33

Post by pjmlp »

kovac wrote: post #18
pjmlp wrote: post #5

Interesting idea, although given the demotion into optional feature in C11, it isn't necessarly portable. Also doesn't cover all the string and memory buffer manipulations. SAL and Frama-C are the bare minimum for security in C code.

What is SAL?

Besides the sibling comment, SAL was born out of the security efforts to fix Windows XP that ended up with the release of Windows XP SP2.

Re: Neverflow: C macros that guard against buffer overflows

#34

Post by ollien »

ChrisRR wrote: post #26
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.

> 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. GCC even has a warning for this.

Even worse, even if you specify the argument to be "of the type" array, it will actually still decay to a pointer. Basically, this macro will only work if you use it in the same function the array is defined.

https://godbolt.org/z/vr4za73qq

Re: Neverflow: C macros that guard against buffer overflows

#35

Post by epistasis »

kllrnohj wrote: post #29
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…

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.

My comment acknowledged what you state, but then went on to point out that it requires adding a tool chain to compile Rust or C++, neither of which are trivia and which may not exist at all on the target architecture.

Re: Neverflow: C macros that guard against buffer overflows

#36

Post by epistasis »

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.

You seem to be replying to the wrong comment, I am not suggesting that people switch away from C.

Re: Neverflow: C macros that guard against buffer overflows

#37

Post by epistasis »

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.

And yet, even with that, Yann Collet credits Google's use of C++ for the compression library as a critical mistake that allowed him, an unknown, to gain traction with his own compression methods. Google later rewrote their library in C:

https://overcast.fm/+LfVPHmBTo

Even if the tool chain exists, it must be adopted, unless you can rely on binaries being available for your end users, which will never be the case for a library which is just starting our. And adding another dependency to your build process, especially one as complex and with as many breaking version changes as C++, is a lot of work to take on.

Re: Neverflow: C macros that guard against buffer overflows

#38

Post by f33d5173 »

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…

You could extend point 1. by making a convention of always declaring pointers to arrays like so:

  int (*data)[datalen];
This requires you to dereference it once to get an array, then dereference it a second time to get a value. The advantage is that the array value can be used the same as an normal array on the stack, including passing it to the array length macro you describe.

Re: Neverflow: C macros that guard against buffer overflows

#39

Post by CyberDildonics »

oleganza wrote: post #7
frabert wrote: post #2

Never heard of a serious buffer overflow caused by _constant_ indices. Does it work with AT(arr, i), or only with AT(arr, 10)?

"'Brother,' says he, 'greetings. Didn't I see you in Southern Missouri last summer selling colored sand at half-a-dollar a teaspoonful to put into lamps to keep the oil from exploding?' "'Oil,' says I, 'never explodes. It's the gas that forms that explodes.' But I shakes hands with him, anyway. ... "'Listen,' says I. 'I instruct her to keep her lamp clean and well filled. If she does that it can't burst. And with the…

Did you mean to reply somewhere else? This thread is about about bounds checking arrays in the C programming language.

Re: Neverflow: C macros that guard against buffer overflows

#40

Post by adwn »

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.

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

Two years ago, your argument would have implied that Rust would never be allowed into the Linux kernel, and yet here we are.

Post reply on HN