Revoking certain certificates on March 4

Re:Revoking certain certificates on March 4 by heavenlyblue on Tuesday March 03, 2020 @08:41AM (#22474323)

People say Rust’s borrowing rules are only useful for multi-threaded environments. This is one of those issues that they are supposed to solve.

[ Parent | on HN ]

Re:Revoking certain certificates on March 4 by Thaxll on Tuesday March 03, 2020 @11:47AM (#22476142)

I'm not sure I understand, it's a business logic bug, would have happen in any language.

[ Parent | on HN ]

Re:Revoking certain certificates on March 4 by chc on Tuesday March 03, 2020 @12:53PM (#22476910)

How do you figure this is a business logic bug? It looks like a pretty clear-cut implementation bug to me. Rust would 100% have caught this bug, and in fact I'm pretty sure it would have caught the bug at least two different ways:

1. The reference outlives the original value.

2. You can't have multiple mutable references at the same time.

[ Parent | on HN ]

Re:Revoking certain certificates on March 4 by cesarb on Tuesday March 03, 2020 @02:12PM (#22477745)

> 2. You can't have multiple mutable references at the same time.

If I understood the issue correctly, only one of the references would be a mutable one, so the way Rust could have caught the bug would instead be the related rule: "you can't have an immutable reference and a mutable reference at the same time".

[ Parent | on HN ]

Re:Revoking certain certificates on March 4 by SolarNet on Tuesday March 03, 2020 @12:49PM (#22476850)

Except that the reference in question would have caused a lifetime error in rust which would have required the developrs to explictly acknowledge the choice they were making, likely by changing a bunch of types.

Yes you could still do it in rust, but any reviwer of the code would say "why in the world are you doing it this way" because it would be forced into a complex cross call monstrosity.

[ Parent | on HN ]

[dead]

Re:Revoking certain certificates on March 4 by steveklabnik on Tuesday March 03, 2020 @09:51AM (#22474853)

An example from less than a day ago: https://news.ycombinator.com/item?id=22466354

[ Parent | on HN ]

Re:Revoking certain certificates on March 4 by tedunangst on Tuesday March 03, 2020 @12:01PM (#22476303)

I'm not super confident I understand the bug, but it looks like sequential access to the reference. If I'm not mistaken, a mutable borrow in rust would end up with the same bug.

[ Parent | on HN ]

Re:Revoking certain certificates on March 4 by steveklabnik on Tuesday March 03, 2020 @12:23PM (#22476563)

I have not dug into the details enough to say if this is a bug Rust would prevent or not, I am only responding to the claim that people do not sometimes suggest that Rust's complexity only matters in the multi-threaded case.

[ Parent | on HN ]

Re:Revoking certain certificates on March 4 by tedunangst on Tuesday March 03, 2020 @12:28PM (#22476617)

Gotcha.

[ Parent | on HN ]

Re:Revoking certain certificates on March 4 by m-n on Tuesday March 03, 2020 @02:38PM (#22477975)

If I understand correctly, each `authzPB` collected in the iteration stores references to fields of an `authzModel`. Before the patch, these were identical, referring to the fields of the loop variable v. Each iteration of the loop, v is set, and all those stored references pointed to the new value.

Rust does give a compilation error for that.

[ Parent | on HN ]

Re:Revoking certain certificates on March 4 by tedunangst on Tuesday March 03, 2020 @06:20PM (#22479698)

That makes sense.

[ Parent | on HN ]

Re:Revoking certain certificates on March 4 by fortran77 on Tuesday March 03, 2020 @03:18PM (#22478350)

I think you're right, too.

[ Parent | on HN ]

Re:Revoking certain certificates on March 4 by webappguy on Tuesday March 03, 2020 @09:56AM (#22474885)

Do you take issue with Rust?

[ Parent | on HN ]