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

121–130 of 150 posts

Re: Neverflow: C macros that guard against buffer overflows

#121

Post by tialaramex »

FpUser wrote: post #82
tialaramex wrote: post #42

Earlier quoted context omitted.

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.

>"std::array " Unless you mean array of anything like in typeless dynamic languages I do not see anything awkward about STL arrays in C++.

It's a standard library feature, rather than a language feature.

And you might say, "Who cares? Even freestanding has the standard library". Nope, std::array wasn't added to freestanding. You can dig into the messy details for yourself if you want, but suffice to say your freestanding C++ doesn't have std::array

So the C++ language has "arrays" but they're garbage, and if you point out that the arrays are garbage you're told to use this library feature, which may not be available.

Re: Neverflow: C macros that guard against buffer overflows

#122

Post by tialaramex »

pjmlp wrote: post #87
tialaramex wrote: post #76

Earlier quoted context omitted.

I'm kind of on board with this, but the problem is that it's 30 years of rotten wood. Rust started from a more secure foundation and has put a lot of effort into stabilising even the trickier ground - whereas in C++ it's too often "Yeah, we don't think about it too hard, when there are strong winds I don't go up into the top floor, the creaking is very loud, I'd rather just never find out". Example, Rust 1.0 had std:…

Sometimes it is better to have rotten wood to build something than nothing at all. If we want to encourage Rust adoption, it is by having a middle path, not via Rust Advocacy Strike Force. That only shuts the audience off, specially when Rust has a glass ceiling of depending on C++ infrastructure for its reference compilers.

I believe conventionally they're called the Rust Evangelism Strike Force.

And it's true that the rotten wood was better than nothing. Nobody is suggesting that NT or Linux should somehow have been developed in Rust in the 1990s. But likewise we shouldn't resist renewal in newer, better materials.

That applies to compiler internals too. Plenty of trouble down there for C++, it's just that C++ programmers can more often be sent away by assuring them that what they did was UB and so LLVM is entitled to miscompile it whereas the Rust people keep arriving with the receipts, in the form of LLVM IR that is lowered to machine code which makes no sense

e.g. https://github.com/llvm/llvm-project/issues/45725

Re: Neverflow: C macros that guard against buffer overflows

#123

Post by inetknght »

tialaramex wrote: post #121
FpUser wrote: post #82

Earlier quoted context omitted.

>"std::array " Unless you mean array of anything like in typeless dynamic languages I do not see anything awkward about STL arrays in C++.

It's a standard library feature, rather than a language feature. And you might say, "Who cares? Even freestanding has the standard library". Nope, std::array wasn't added to freestanding. You can dig into the messy details for yourself if you want, but suffice to say your freestanding C++ doesn't have std::array So the C++ language has "arrays" but they're garbage, and if you point out that the arrays are garbage you…

The only valid complaint about std::array is that it's awkward to declare and takes more characters to type. It is, otherwise, vastly superior in every other way.

That doesn't make them garbage. That makes them annoying.

Re: Neverflow: C macros that guard against buffer overflows

#124

Post by inetknght »

uecker wrote: post #66
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.

> These are dependent types which C++ does not have at all.

As a C++ developer, that sounds strange. Can you point me to some documentation about "dependent types"?

Re: Neverflow: C macros that guard against buffer overflows

#125

Post by BearOso »

adwn wrote: post #40
coliveira wrote: post #31

Earlier quoted context omitted.

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.

Rust in the kernel is a whole different beast than what most people think--no standard library, no cargo or external crates, some memory safety features removed. It's kind of just an alternative syntax.

Re: Neverflow: C macros that guard against buffer overflows

#126

Post by ActorNightly »

duped wrote: post #62
ActorNightly wrote: post #47

Earlier quoted context omitted.

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?

>Except it's being used for serious development today

No, its being used for pet projects by people. Serious development = major companies using it in backends.

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

Because of CS programs, and legacy software written in java. Java has a community dedicated to pushing theoretical CS concepts into the language (much like Rust), while allowing things like a logging library to fetch code from anywhere on the internet and execute it, by default (which I would bet on would be the future of Rust given current trajectory)

Re: Neverflow: C macros that guard against buffer overflows

#127

Post by c-cube »

ActorNightly wrote: post #126
duped wrote: post #62

Earlier quoted context omitted.

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

>Except it's being used for serious development today No, its being used for pet projects by people. Serious development = major companies using it in backends. >So one of the most widely used applications programming languages in the world? Because of CS programs, and legacy software written in java. Java has a community dedicated to pushing theoretical CS concepts into the language (much like Rust), while allowing…

> No, its being used for pet projects by people. Serious development = major companies using it in backends.

You mean companies like Dropbox, Cloudflare, Amazon, Microsoft...? Are they too small to be relevant?

Re: Neverflow: C macros that guard against buffer overflows

#128

Post by nerpderp82 »

kazinator wrote: post #95

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 tha…

Benchmark it after -O3, does it really matter ?

Re: Neverflow: C macros that guard against buffer overflows

#129

Post by nerpderp82 »

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…

> bit of discipline

Re: Neverflow: C macros that guard against buffer overflows

#130

Post by skullchap »

cornstalks wrote: post #92

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; }

[dead]
Post reply on HN