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

61–70 of 150 posts

Re: Neverflow: C macros that guard against buffer overflows

#61

Post by pjmlp »

tialaramex wrote: post #42
inetknght wrote: post #12

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

But this isn't something the C++ language provides, which is hilarious. C++ keeps C's crap array type as its native array type. You need to reach into the C++ standard library to get this awkward library type, std::array and then finally you get an array type that remembers how big it is and has some basic features like swap.

True, but it also adds lot of features that help to easily migrate to saner features without rewriting the world and throw away 30 years of tooling.

Microsoft security team is on the record that just because they are adopting Rust, they won't shy away from C++.

Re: Neverflow: C macros that guard against buffer overflows

#62

Post by duped »

ActorNightly wrote: post #47
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…

Rust is by far not mature enough for serious development. Recent shenanigans with crablang are a strong sign of it going down the route of Java, i.e a corporate developed language with offshoots, which will end up with Rust being in the same crappy state.

> Rust is by far not mature enough for serious development

Except it's being used for serious development today

> going down the route of Java, i.e a corporate developed language with offshoots, which will end up with Rust being in the same crappy state.

So one of the most widely used applications programming languages in the world?

Re: Neverflow: C macros that guard against buffer overflows

#63

Post by pjmlp »

CyberDildonics wrote: post #39
oleganza wrote: post #7

Earlier quoted context omitted.

"'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.

You definitly didn't understood the message.

Re: Neverflow: C macros that guard against buffer overflows

#64

Post by astrobe_ »

adastra22 wrote: post #58
6D794163636F756 wrote: post #50

Earlier quoted context omitted.

C never has just one way to do something. myArr[5] == 5[myArr] == (insert pointer arithmetic that I won't write here without a compiler check). I think that part of C's beauty is that it gives you freedom. Freedom to shoot yourself in the foot, freedom to write hyper efficient code, and freedom to choose another tool. I agree that this will never be implemented as a standard, but I think that's a good thing. Higher l…

Those are syntactic sugar for the same thing though. Array[5] is just shorthand for *(Array + 5), which is why 5[Array] also works (because addition is commutative). Note that C does have strong conventions, such as that strings are terminated by a zero byte. Nothing in the language demands that, it’s just a convention! C could adopt better conventions.

> 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.

Re: Neverflow: C macros that guard against buffer overflows

#65

Post by jacquesm »

pjmlp wrote: post #57
coliveira wrote: post #31

Earlier quoted context omitted.

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

They better improve their error free coding skills when liability laws come for them.

This I can't wait for but the bigger problem will be that the rest of the development process is at least as broken as the languages are.

Re: Neverflow: C macros that guard against buffer overflows

#66

Post by uecker »

inetknght wrote: post #12

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

These are dependent types which C++ does not have at all. The C support is fairly weak though... But most programming language people I know agree that dependent types are they way to guard against overflow with minimal overhead. So hope we can evolve C in this direction.

Re: Neverflow: C macros that guard against buffer overflows

#67

Post by thelopa »

adastra22 wrote: post #58
6D794163636F756 wrote: post #50

Earlier quoted context omitted.

C never has just one way to do something. myArr[5] == 5[myArr] == (insert pointer arithmetic that I won't write here without a compiler check). I think that part of C's beauty is that it gives you freedom. Freedom to shoot yourself in the foot, freedom to write hyper efficient code, and freedom to choose another tool. I agree that this will never be implemented as a standard, but I think that's a good thing. Higher l…

Those are syntactic sugar for the same thing though. Array[5] is just shorthand for *(Array + 5), which is why 5[Array] also works (because addition is commutative). Note that C does have strong conventions, such as that strings are terminated by a zero byte. Nothing in the language demands that, it’s just a convention! C could adopt better conventions.

Many of the str functions in the C standard library assume a nul terminator.

Re: Neverflow: C macros that guard against buffer overflows

#68

Post by hinkley »

ActorNightly wrote: post #44
eqvinox wrote: post #8

The problem with C and buffer overflows isn't that you can't guard against them, or that there is no existing, reusable code to do so — it's that none of this functionality is standardized. Adding another one to the existing 41383 ways of doing this is in fact the exact opposite of what's needed. Ideally C needs one way of doing this, and that would be described in the standard. But that's not how C "rolls", and we'l…

There is value in actually understanding what someone is doing in regards to protecting against buffer overflows, instead of relying on well established patterns.

Not when I’m trying to orchestrate third party libraries.

Re: Neverflow: C macros that guard against buffer overflows

#69

Post by uecker »

ollien wrote: post #34
ChrisRR wrote: post #26

Earlier quoted context omitted.

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

You need to pass a pointer to an array: https://godbolt.org/z/jYzY79ac4

When passing an array it decays into a pointer and the size is lost. We can also change sizeof to recover it, but there was a proposal for a _Lengthof operator which could work here.

Re: Neverflow: C macros that guard against buffer overflows

#70

Post by Joker_vD »

pjmlp wrote: post #63
CyberDildonics wrote: post #39

Earlier quoted context omitted.

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

You definitly didn't understood the message.

But it's absolutely true though: if only the C programmers right their code very carefully and in specific patterns, the buffer overflows and invalid dereferences won't happen and therefore, won't explode their programs! By the way, only today I have a silver bullet to sell with "runtime safety violations" written on it, anyone willing to buy it?
Post reply on HN