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

91–100 of 143 posts

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

#91

Post by Someone »

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 constructs that are valid, but hard to prove or is the error not always triggered for buggy code?

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

#92

Post by constantcrying »

the__alchemist wrote: post #88
constantcrying wrote: post #80

Earlier quoted context omitted.

>Can you think of any other languages? Yes. E.g. every language where you can pass pointers can do this. Reference are a construct around pointers. >Of the ones I listed, I use all of, and am continuously frustrated by this limitation. Why? This is only a limitation for a few basic types. All the language you mention allow you to modify objects passed to a function. If it ever were any issue though you can always ret…

You're correct re the class wrapper (HN nesting limit). Can you see why that solution is complicated, and not versatile? (hint: This limitation will cause ripples of complication throughout your data structures)

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 up on your data structures. The need to pass a modifiable data structure almost never arises, the idiom in your OP is extremely uncommon and would likely not pass any code review.

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

#93

Post by foota »

bluGill wrote: post #53

Why is garbage collection called memory safety? Garbage collection in whatever form is only memory safe if it doesn't free memory that will still be used. (which means if you actually get all your free calls correct C is memory safe - most long lived C code bases have been beat on enough that they get this right for even the obscure paths). Use after free is important, but in my experience not common and not too hard…

To answer your question, I'd say it's memory safe when it's a part of the runtime. At some point, you're relying on your runtime to be correct, so if it says it does garbage collection then you can rely on it, in the same way you rely on the allocator not to randomly trash your memory etc.,.

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

#94

Post by bloppe »

chrismorgan wrote: post #8

> Curséd With an acute accent, that should be roughly /ˌkɜːrˈseɪd/ “curse-ay-d”. (Think “café” or “sashayed”.) The stylised pronunciation being evoked is roughly /ˈkɜːrˌsɛd/, “curse-ed”, and would be written with a grave accent: “cursèd”.

Accents mean different things in different languages. I'm assuming the author was invoking Spanish, where the acute accent impacts syllable stress but not pronunciation.

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

#95

Post by zozbot234 »

johnnyjeans wrote: post #70
amelius wrote: post #51

Earlier quoted context omitted.

> If GC is an option and you want all the nice parts of Rust, use OCaml So are you saying it would be possible to use a hypothetical "non-GC-enabled" OCaml compiler that complains if GC'd code is invoked/generated, and it would be a similar experience as using Rust?

No, simply because GC isn't an optional part of ocaml's design. You can "disable" it only in the sense that you stop any frees from happening. In order to do away with Garbage collection you'd need to completely change the type system, and while you might get a result which ends up looking a lot like ocaml, it won't be ocaml any more than ocaml is sml. This is what Rust started out as, by the way. In my opinion, it s…

Early versions of Rust "started out" with GC: the language was broadly similar to Golang, though with a lot of influence from Ocaml and functional languages more broadly. The comprehensive use of borrowck to avoid GC altogether was only implemented around 2014 or so, hence shortly before the Rust "1.0" release in 2015.

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

#96

Post by jandrewrogers »

obl wrote: post #22
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.

It is not ridiculous at all. Those things have pretty precise definitions and type segregation absolutely does remove a bunch of soundness issues related to type confusion. You can think of it as the rather classic "Vec of struct + numeric IDs" that is used a lot e.g. in Rust to represent complex graph-like structures. This combined with bound checking is absolutely memory safe. It has a bunch of correctness issue th…

FWIW, arrays of structs + integer handles is the primary way objects are represented in performance-engineered C++.

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

#97

Post by the__alchemist »

constantcrying wrote: post #92
the__alchemist wrote: post #88

Earlier quoted context omitted.

You're correct re the class wrapper (HN nesting limit). Can you see why that solution is complicated, and not versatile? (hint: This limitation will cause ripples of complication throughout your data structures)

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 have missed the point: Functions should not need to be provincial to a specific data structure. Nor should data structures include field wrappers to subvert a language's sloppy mutation semantics.

The point is that with mutable references, you can modify only the part of the struct you need to, using a general function. You can use this same function to modify a different part of the structure, or a different structure, or a free variable.

Your inference that preferring mutable references to wrapper structs implies insufficient knowledge of data structures is puzzling and incorrect.

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

#98

Post by jimbob45 »

mastax wrote: post #50
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...

Yeah C# is very well designed for gradually introducing low level concepts for performance.

The reverse is arguably the one trait Rust is missing that is holding it back from mass adoption. You can write high-level C# code and seamlessly introduce low-level concepts into it as you see fit. However, although you can write low-level Rust code easily, introducing high-level concepts is very painful and, in many cases, impossible.

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

#99

Post by bluGill »

constantcrying wrote: post #75
bluGill wrote: post #53

Why is garbage collection called memory safety? Garbage collection in whatever form is only memory safe if it doesn't free memory that will still be used. (which means if you actually get all your free calls correct C is memory safe - most long lived C code bases have been beat on enough that they get this right for even the obscure paths). Use after free is important, but in my experience not common and not too hard…

>Why is garbage collection called memory safety? Garbage collection in whatever form is only memory safe if it doesn't free memory that will still be used. Yes. A garbage collector is only safe if it works correctly. What an irrelevant observation. Nothing can guarantee that something works correctly if it doesn't work correctly.

Keep reading. That is all a garbage collector gives me. there are lots of other things that that are memory unsafe that garbage collectors don't give me.

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

#100

Post by constantcrying »

constantcrying wrote: post #92
the__alchemist wrote: post #88

Earlier quoted context omitted.

You're correct re the class wrapper (HN nesting limit). Can you see why that solution is complicated, and not versatile? (hint: This limitation will cause ripples of complication throughout your data structures)

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 is why types exists.

Post reply on HN