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

Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches

verdagon.dev

Post reply on HN
Print view View original

101–110 of 143 posts

Re: Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches

#101

Post by the__alchemist »

constantcrying wrote: post #100
constantcrying wrote: post #92

Earlier quoted context omitted.

I explicitly excluded primitive types in my previous comment. I have never seem a codebase where this was an issue. The most important concept in programming is defining your data structures. Professional programs almost never operate on primitive data structures, but always on larger structures, like classes or structs. This is why this is only a problem for you. I don't want to be insulting, but you need to brush u…

You don't need to wrap fields. You just pass the classes. Think about why nobody but you is inconvenienced by this. I am sorry, this is a you problem, because you are violating common idioms of the language. There is basically never a reason not to pass your data structure to a function, which is why what you are doing is an incredibly niche functionality. Also functions should be particular to data structure. That i…

General functions are useful.

It is not a me problem, which is why Rust has fixed this. You are arguing that functions which mutate parameters generally are not useful, which isn't true. You have implied that I have a lack of knowledge of data structures, my code wouldn't pass code review. Reflect: You are proposing it is preferable to have a simple function accept a whole data structure when it may only act on one or more of its fields, and may be used in other places. That is a semantic misdirection, and provincialization.

Re: Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches

#102

Post by renox »

the__alchemist wrote: post #79
constantcrying wrote: post #78

Earlier quoted context omitted.

>I've seen usually involve pointers. If only C++ had a thing called "references", which conveniently also used the "&" symbol and are a way to do exactly this without pointers. https://en.cppreference.com/w/cpp/language/reference

I stand corrected on C++. Can you think of any other languages? Of the ones I listed, I use all of, and am continuously frustrated by this limitation.

Ada has inout parameters.

Re: Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches

#103

Post by mgaunard »

eddd-ddde wrote: post #82
mgaunard wrote: post #11

The fact that re-using a slot for a different object of the same type is considered a memory safety technique is ridiculous.

Are you implying that it is unsafe? Or that it is unrelated to safety properties?

It just shows memory safety is a joke, simply replacing a class of bugs with another.

Re: Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches

#104

Post by dwattttt »

adgjlsfhk1 wrote: post #69
shiomiru wrote: post #13

Earlier quoted context omitted.

> Have you considered what happens if not-utf8 data winds up in an environment variable that you are writing to stdout? What if it contains malicious VT commands? Unless you're talking about terminal bugs in parsing invalid UTF-8 - and parsing invalid UTF-8 is easier than rendering valid UTF-8 - VT commands are UTF-8 compatible. You just need to embed an ASCII escape character.

yeah I think this is an area where rust (and python) just get it wrong. files, the Internet and input devices can all give you invalid Unicode. IMO it's better to have a primary string type that includes invalid Unicode since most algorithms will handle it correctly anyway, and the ones that won't can pretty clearly check and throw errors appropriately (especially since very few algorithms work correctly for all of U…

There's a primary type that holds invalid utf8; it's [u8]. If you want a string from that, you try turn it into a string, and deal with the errors then.

If an algorithm works for invalid Unicode, it should probably be an algorithm on bytes, not strings.

Re: Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches

#105

Post by IshKebab »

mgaunard wrote: post #103
eddd-ddde wrote: post #82

Earlier quoted context omitted.

Are you implying that it is unsafe? Or that it is unrelated to safety properties?

It just shows memory safety is a joke, simply replacing a class of bugs with another.

It isn't a joke. With memory safety bugs the value of an object can unexpectedly be any bit pattern. That breaks the assumptions of basically every language and leads to pretty much anything happening.

If you have an array of objects of the same type and you just pick the wrong one, then the data still has to be a valid bit pattern. Yes it might still be a security bug, but it's much less likely because you aren't completely subverting the language.

Surely you don't think all bugs are the same because they are all bugs?

Re: Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches

#106

Post by ptx »

mgaunard wrote: post #11

The fact that re-using a slot for a different object of the same type is considered a memory safety technique is ridiculous.

Maybe we need to introduce the term "value safety" to complement "type safety".

If a language is merely type-safe, then it might be OK to silently replace a value with a different one of the same type, sure, fine. Who cares if the program transmits the wrong message to the wrong recipient as long as it's definitely some message and some recipient?

But a value-safe language, I suggest, is one that doesn't pull this kind of switcheroo.

Re: Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches

#107

Post by dwattttt »

pjmlp wrote: post #37
f1shy wrote: post #31

Earlier quoted context omitted.

Yet another PoV: for some things with critical timing or so, GC might be a problem. But most of the time, it isn’t. The performance/predictability topic could also be reviewed… I was talking with a colleague about that, he said “in C I know exactly where things are when” And I replied that under any OS with virtual memory, you have basically no clue where are things at any time, in the N levels of cache, and you cann…

Even with critical timing, real time GCs exist for decades now, PTC and Aicas are two surviving companies selling software tooling for embedded markets, including their own JVM implementations, with AOT compilers, bare metal deployments and real time GC. Many of their customers are factory processes and military deployments with weapons control, two scenarios where any kind of stall might produce deadly results.

While I agree with the point, the word "surviving" doesn't do that point any favours.

Re: Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches

#108

Post by jcarrano »

mgaunard wrote: post #11

The fact that re-using a slot for a different object of the same type is considered a memory safety technique is ridiculous.

Reminds me of a video I saw about "cloning" on Super Mario 64[1]. SM64 uses slots and one can mess around with slot deletions to get random objects.

[1] https://www.youtube.com/watch?v=X2AhyDI58-I

Re: Borrow Checking, RC, GC, and Eleven Other Memory Safety Approaches

#109

Post by naasking »

Someone wrote: post #91
naasking wrote: post #40

More people need to read up on C#'s ref's: https://em-tg.github.io/csborrow/ These kinda-sorta fall under borrow checking or regions, just without any annotations. Then again, Ada/Spark's strategy also technically falls under Tofte-Talpin regions: https://www.cs.cornell.edu/people/fluet/research/substruct-r...

Isn’t that a form of “5. a mechanism where a pointer cannot point to an object that is more deeply scoped than itself” ? Also, since it’s an error, I guess it must be different from gcc and clang (and, likely other C compilers) -Wreturn-local-addr warnings ( https://www.emmtrix.com/wiki/Clang:Flag/-Wreturn-local-addr ), which can have false positives. What’s the difference? Is the language stricter, disallowing some…

> Isn’t that a form of “5. a mechanism where a pointer cannot point to an object that is more deeply scoped than itself”?

That constraint is just a Tofte-Talpin region restriction, eg. lexically scoped regions.

Post reply on HN