Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Memory safety absolutists

itsallaboutthebit.com

Post reply on HN
Print view View original

51–60 of 272 posts

Re: Memory safety absolutists

#51

Post by yjftsjthsd-h »

saghm wrote: post #45
yjftsjthsd-h wrote: post #22

> But Rust is unsafe, isn't it? It has unsafe after all! If you want to be that strict, or in other words, if you are a memory safety absolutist, that may well be true for you. I, and I hope most people, am more pragmatic than that. So... Yes, Rust is less safe. Just that now the Rust apologist wants to back away from that and say that actually memory safety isn't actually the end all be all. C has a lot of security…

You can just...not use it though? It's not comparable to trying to avoid it in C/C++ because there's literally just one keyword to never use and then you're good, compared to it being possible to silently introduce in any number of ways. I put a lint in my Cargo.toml to forbid unsafe code in my projects, and now I'm guaranteed not to write unsafe code. To apply your logically consistently, you'd also have to throw ou…

> To apply your logically consistently, you'd also have to throw out Go[1], Java[2], C#[3], and plenty of other languages

Yes? Is Fil-C not obviously safer than those?

> I guess you can define a logically consistent taxonomy of languages where Fil-C is the only "safe" language any everything else is unsafe, but then the burden is on you to prove that it's a useful way of thinking about them. Meanwhile, the way that people who consider Go and Java and Rust to be safe and C/C++ to be unsafe will continue to see actual real-world differences in outcomes when using a safe language compared to unsafe ones.

It seems like "can switch on unsafe whenever" vs "has no escape hatches" is an obvious line in the sand and a very useful distinction with real world implications.

> Maybe Fil-C will be able to provide as large benefits to running C safely in production like its proponents claim in the future

Why in the future? It exists and can be used right now. In fact, much of its appeal is being able to use existing code without needing to port to a new language; pragmatism seems like an argument in its favor.

Re: Memory safety absolutists

#52

Post by rowanG077 »

muvlon wrote: post #50
rowanG077 wrote: post #5

Something that is important to me is that it's caught at compile time. A memory issue is a logic bug. Fil-c simply moves that from undefined behavior/security issue/incorrectness to a crash. That's better than what it was. But I generally don't want my programs to crash. Having memory safety at compile time is much more worthwhile imo.

As a Rust fanboy, I have to concede that Rust also doesn't have pure compile-time memory safety. Some checks are runtime there as well, in particular most of bounds safety.

I agree. Rust does not go far enough imo. Still catching most memory problems at compile time is still much superior.

Re: Memory safety absolutists

#53

Post by himata4113 »

consumer451 wrote: post #23
himata4113 wrote: post #2

My biggest problem with the refusal to be memory safe is the fact that those problems end up becoming my problems when I am forced to use these applications and I have to think about how there might be a zero-click zero-day that uses an overflow in some random codec. Not as a software developer, but a regular person I want my application to be written in rust or at least use fil-c at bare minimum. Now as a software d…

It seems to me that memory safety might be the difference between the software engineering and Software Engineering. As in, an actual Engineering discipline. However, I should probably pipe down, as I would not call myself either one.

There are too many opensource projects that show that even with good engineering discipline humans are flawed creatures.

Memory safety is just little thing that makes sure that when you write code at 4am that it will not leak memory via trivial mistakes such as forgetting to free something, freeing something twice or passing a freed pointer. I believe AI agents shine here the most because the they do not get tired and are getting pretty damn predictable.

Re: Memory safety absolutists

#55

Post by [deleted] »

himata4113 wrote: post #53
consumer451 wrote: post #23

Earlier quoted context omitted.

It seems to me that memory safety might be the difference between the software engineering and Software Engineering. As in, an actual Engineering discipline. However, I should probably pipe down, as I would not call myself either one.

There are too many opensource projects that show that even with good engineering discipline humans are flawed creatures. Memory safety is just little thing that makes sure that when you write code at 4am that it will not leak memory via trivial mistakes such as forgetting to free something, freeing something twice or passing a freed pointer. I believe AI agents shine here the most because the they do not get tired an…

[deleted]

Re: Memory safety absolutists

#56

Post by Animats »

rowanG077 wrote: post #52
muvlon wrote: post #50

Earlier quoted context omitted.

As a Rust fanboy, I have to concede that Rust also doesn't have pure compile-time memory safety. Some checks are runtime there as well, in particular most of bounds safety.

I agree. Rust does not go far enough imo. Still catching most memory problems at compile time is still much superior.

The important thing from a performance standpoint is to be able to hoist bounds checks out of inner loops. This avoids a check on each iteration. Languages which have constructs such as

   for foo in bartab {}
can usually hoist checks out of inner loops almost for free.

I used to argue with the C++ committee about to when it's OK to catch an error early. If you write

    #define LEN 1000
    int tab[LEN];
    for (auto p = tab; p++; p
that's a buffer overflow. The question is, is the compiler allowed to generate checking code which will abort the program before entering the loop? Or does it have to execute all the iterations up to the subscript error?

I argued that it's legit to catch an error at the point it becomes inevitable. This leads to bikeshedding objections: "But what if a signal interrupts the loop before it runs off the end". That's why you need a language where undefined behavior has been nailed down to do this optimization properly.

Re: Memory safety absolutists

#57

Post by saghm »

yjftsjthsd-h wrote: post #51
saghm wrote: post #45

Earlier quoted context omitted.

You can just...not use it though? It's not comparable to trying to avoid it in C/C++ because there's literally just one keyword to never use and then you're good, compared to it being possible to silently introduce in any number of ways. I put a lint in my Cargo.toml to forbid unsafe code in my projects, and now I'm guaranteed not to write unsafe code. To apply your logically consistently, you'd also have to throw ou…

> To apply your logically consistently, you'd also have to throw out Go[1], Java[2], C#[3], and plenty of other languages Yes? Is Fil-C not obviously safer than those? > I guess you can define a logically consistent taxonomy of languages where Fil-C is the only "safe" language any everything else is unsafe, but then the burden is on you to prove that it's a useful way of thinking about them. Meanwhile, the way that p…

> It seems like "can switch on unsafe whenever" vs "has no escape hatches" is an obvious line in the sand and a very useful distinction with real world implications.

Sure, although to me, the obvious distinction is that one of them gives you more flexibility (since neither Go nor Fil-C is at risk for someone accidentally writing unsafe code).

> Why in the future? It exists and can be used right now. In fact, much of its appeal is being able to use existing code without needing to port to a new language; pragmatism seems like an argument in its favor.

Because "can be used" is not a statement of present use, but potential future use. You seem to be missing my entire point about theory versus practice; plenty of things might be useful in theory but don't ever get widely used in practice (e.g. because they're not user friendly enough, or they require constraints that aren't acceptable to most users). I'm not making a claim about whether Fil-C has these issues, but making a claim that as yet, there does not seem to be widespread usage of it. If it's really so seamless to drop-in as a replacement for C that's strictly safer without downsides that make it unappealing to most people, I'd expect that to change. If that doesn't happen, I'd consider that evidence that it's not actually providing meaningful safety in the real world (in the https://xkcd.com/1312/ sense)

Re: Memory safety absolutists

#58

Post by inigyou »

bpavuk wrote: post #16
inigyou wrote: post #12

I don't think you need to be an absolutist or only use memory safe languages but it's very obvious that we need to do a whole lot better than we actually do. Rewriting in Rust or any other language is one way to do that, but not a perfect one. I'll accept C++ when most C++ software has 1 in 50 chance of an RCE and not just a 1 in 50 chance of a known RCE. I think we can get there but we are not currently there. Coreu…

ffmpeg is actually asm and for a good reason - it has to go fucking fast or else media playback will take too much resources

Great then let's prove that ASM is correct.

the reference C code is just as bad.

Re: Memory safety absolutists

#59

Post by pizlonator »

throwlifeaway wrote: post #4

Pizlo is not a memory safety absolutist. His rhetoric towards rust is a tactic specifically designed to draw more attention to him and his project. It is amplified by people who already had a bone to pick with rust and take joy in giving rust folk "a taste of their own medicine," so to speak. Articles like this are taking the bait.

What a weird take.

I think the limits of Rust’s memory safety are interesting to discuss, as are the limits of Fil-C’s perf and practicality.

It’s best to discuss these things rationally, rather than accusing folks of trying to draw attention

Re: Memory safety absolutists

#60

Post by pizlonator »

Animats wrote: post #49

Trying to figure out Fil-C's "inviscaps".[1] When you allocate space with Fil-C's "malloc", some additional bounds checking data precedes the space the program gets to use. Pointers are "fat pointers", with a pointer to the beginning of the buffer and a pointer to someplace within the buffer, allowing ordinary C pointer manipulation. There's much new verbiage around this. But it's roughly the same idea as GCC "fat po…

Invisicaps are not exactly fat pointers.

Fat pointers show up inline in memory, which has a bunch of problems:

- sizeof(void*) changes

- either you let the bounds get corrupted by bad casts, unions, and other issues, or you impose restrictions that prevent unions from working compatibly, or you end up supporting unions by having issues with races, or you need special hardware. Invisicaps sidestep all of those issues

Post reply on HN