Internals of Go's new fuzzing system

Re:Internals of Go's new fuzzing system by morelisp on Friday February 18, 2022 @11:47AM (#30388028)

Fair I guess - of those I only used Fortran and not in an environment which supported the colon syntax. (Once you've chosen the wrong way to address array elements of course you'll end up with the wrong way to denote bounds, to take the contrapositive of the classic Djikstra note.)

But in this thread we're talking about Go - and the syntax is also used in Python and Ruby and with the same semantics `..` in Rust - and above all else the notation was clear from my question when I explicitly said those sets were disjoint - and that question is the much more interesting thing, I think?

[ Parent | on HN ]

Re:Internals of Go's new fuzzing system by thetallstick on Friday February 18, 2022 @03:20PM (#30390546)

If i==j==k then they’re not disjoint.

[ Parent | on HN ]

Re:Internals of Go's new fuzzing system by morelisp on Friday February 18, 2022 @03:46PM (#30390839)

Then they're both zero length and a zero-length set is disjoint from all other sets.

Anyone want to explain why Rust needs to explicitly de-alias this yet? What a useless digression...

[ Parent | on HN ]

Re:Internals of Go's new fuzzing system by tialaramex on Friday February 18, 2022 @07:37PM (#30393224)

Why LLVM needs this explaining? Probably somewhere an optimiser could inspect something and it doesn't.

Rust cuts the slice in half and swaps between the halves, so probably LLVM doesn't convince itself that if you did those swaps directly they aren't ever aliased, but once there are two slices which can't overlap it can see it's fine.

[ Parent | on HN ]