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

141–150 of 150 posts

Re: Neverflow: C macros that guard against buffer overflows

#141

Post by tialaramex »

pjmlp wrote: post #133
tialaramex wrote: post #122

Earlier quoted context omitted.

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

Yet if I want to contribute to Rust backend, or its upcoming GCC implementation, write C++ I must. Same applies to the runtimes of the languages I use at work, and GPGPU related tooling when not using shaders. Maybe then do a Go/zig/D, focus on cranelift and fully bootstrap Rust, before trying to rewrite the world.

You certainly can go work on Cranelift or similar projects which have a coherent IR as a central goal rather than eh, it's probably good enough to compile C++.

Re: Neverflow: C macros that guard against buffer overflows

#142

Post by ranger_danger »

JohnFen wrote: post #108
ranger_danger wrote: post #105

Earlier quoted context omitted.

Could you mention one of them?

Sure. For instance, there are times when you need to pack strings tightly together. Adding an extra byte or two before the start of the string would get in the way. You could work around it in many cases, but it makes the code uglier and harder to understand/maintain. One of the things that makes C particularly suitable for certain sorts of tasks is that it's mostly WYSIWYG when it comes to the relationship between d…

if you wanted to pack strings together tightly, couldn't your string library have a separate "array" concept where all the sizes are stored separately?

Re: Neverflow: C macros that guard against buffer overflows

#143

Post by insanitybit »

pjmlp wrote: post #139
junon wrote: post #111

Earlier quoted context omitted.

That's not C++ tooling. That's tooling written in C++. Two very different things.

Word games, those are domains dominated by C++, take the meaning the way it makes you happier.

You're saying word games but you're arguing something that the poster I replied to wasn't saying.

Re: Neverflow: C macros that guard against buffer overflows

#144

Post by FpUser »

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…

>"feature, which may not be available"

Never been into this situation so from a practical standpoint it means zilch to me.

Re: Neverflow: C macros that guard against buffer overflows

#145

Post by FpUser »

tialaramex wrote: post #135
inetknght wrote: post #123

Earlier quoted context omitted.

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.

I feel like I already explained it's not even part of the language itself, it's a library feature, you aren't given this feature without the rest of the hosted C++ standard library. Which is fine if you write Windows desktop apps, but this is an array type, unlike a GUI widget, or an XML parser, it seems like I'd probably want an array type for this $1 per unit micro controller I'm writing firmware for. In Rust the n…

You do not have to butcher. Standalone allocation free implementations are available if you are so in need.

But I see that you bring Rust in here. If that's your cup of tea then use it. No need to spill venom. Personally if I am dealing with $1 micros I very much prefer C with some selected libs for embedded. Do not really have problems with it for such small tasks.

Re: Neverflow: C macros that guard against buffer overflows

#146

Post by FpUser »

inetknght wrote: post #123
tialaramex wrote: post #121

Earlier quoted context omitted.

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.

>"takes more characters to type."

I have never perceived it as a problem. I do not think it really slows my programming. Personally I am the guy who would prefer function() vs fn() but without going into extremes of Java culture. Besides you can always alias it to whatever you want if your fingers are so sensitive.

Re: Neverflow: C macros that guard against buffer overflows

#147

Post by lelanthran »

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…

> And it [calloc] checks whether the result of multiplying them fits in a size_t.

I never knew this was part of the standard. No documentation I saw for calloc (manpages, or similar) ever said it checked for overflow.

Re: Neverflow: C macros that guard against buffer overflows

#148

Post by c-cube »

ActorNightly wrote: post #136
c-cube wrote: post #127

Earlier quoted context omitted.

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

Very few things in those companies are being written in Rust, and half of those projects chose Rust around ideological reasons rather than technical, with plenty of 'unsafe' thrown in for performance reasons https://github.com/firecracker-microvm/firecracker/search?q=... The fact that 'unsafe' even exists in Rust means it's no better than C with some macros. Don't get me wrong, Rust has it's place, like all the other…

You're moving the goalposts here. Rust is being used, in significant projects (eg: proxies at Cloudflare, a company where http is somewhat of a big deal: https://blog.cloudflare.com/introducing-oxy/ ; Dropbox's new sync algorithm, a company where file syncing id kind of a big deal : https://dropbox.tech/infrastructure/rewriting-the-heart-of-o...).

Equating the existence of unsafe with C is laughable imho (it'd be barely comparable even if 100% of the rust code was in unsafe blocs, which never happens). Not even then it doesn't matter for the original point : rust is used in production for business critical functions, in large companies.

Re: Neverflow: C macros that guard against buffer overflows

#149

Post by ActorNightly »

c-cube wrote: post #148
ActorNightly wrote: post #136

Earlier quoted context omitted.

Very few things in those companies are being written in Rust, and half of those projects chose Rust around ideological reasons rather than technical, with plenty of 'unsafe' thrown in for performance reasons https://github.com/firecracker-microvm/firecracker/search?q=... The fact that 'unsafe' even exists in Rust means it's no better than C with some macros. Don't get me wrong, Rust has it's place, like all the other…

You're moving the goalposts here. Rust is being used, in significant projects (eg: proxies at Cloudflare, a company where http is somewhat of a big deal: https://blog.cloudflare.com/introducing-oxy/ ; Dropbox's new sync algorithm, a company where file syncing id kind of a big deal : https://dropbox.tech/infrastructure/rewriting-the-heart-of-o... ). Equating the existence of unsafe with C is laughable imho (it'd be ba…

When an OS is written in Rust fully, then we can talk about acceptance.

Parts of systems written in a language doesn't really mean anything for its adoption into mainstream. For example, Amazon uses Ruby heavily for a bunch of deployment stuff, but Ruby (sans Ruby on Rails that is in decline), is not really a mainstream language any more.

>Equating the existence of unsafe with C is laughable imho

Im not comparing it. The point is to demonstrate that unsafe exists for the sole reason of performance. In fast code you often want to directly access x[y] where x and y are variables, without having to run extra code around it. Its a well known computer science thing, as most of the code challenges given in interviews rely on this access pattern for optimal solutions.

And because of Rice theorem, a compiler cannot determine whether x[y] is always safe, as determining all the values y could take would involve running the program.

So as such, for all the advantages that Rust offers, you can have the same advantages with C with macros and LLVM extensions, albeit with less concise syntax.

https://www.microsoft.com/en-us/research/project/checked-c/

Similar arguments were used to justify Haskel about 6-7 years ago, and Haskel is pretty much dead in the water at this point.

The modern way to make a memory safe language is to focus on a high level language that doesn't require programmer to deal with memory directly, and then work on the compiler to make the resultant code optimal.

Re: Neverflow: C macros that guard against buffer overflows

#150

Post by c-cube »

ActorNightly wrote: post #149
c-cube wrote: post #148

Earlier quoted context omitted.

You're moving the goalposts here. Rust is being used, in significant projects (eg: proxies at Cloudflare, a company where http is somewhat of a big deal: https://blog.cloudflare.com/introducing-oxy/ ; Dropbox's new sync algorithm, a company where file syncing id kind of a big deal : https://dropbox.tech/infrastructure/rewriting-the-heart-of-o... ). Equating the existence of unsafe with C is laughable imho (it'd be ba…

When an OS is written in Rust fully, then we can talk about acceptance. Parts of systems written in a language doesn't really mean anything for its adoption into mainstream. For example, Amazon uses Ruby heavily for a bunch of deployment stuff, but Ruby (sans Ruby on Rails that is in decline), is not really a mainstream language any more. >Equating the existence of unsafe with C is laughable imho Im not comparing it.…

https://www.redox-os.org/
Post reply on HN