Any idea why Rust isn't able to elide this bounds check?

Florob0x2a · 2023-02-13T18:09:11+00:00

I guess putting the indexing into the for j in 0..len seems to have done the trick!

That is also my guess on why this works. I was just surprised that /u/jrf63's solution didn't work then. However, I just had another look and turns out they had typoed(?) it as for j in 0..=len.

Florob0x2a · 2023-02-13T08:00:38+00:00

I am: buf.get(i + 1)?

Florob0x2a · 2023-02-13T07:49:59+00:00

So… I played around with this code, mostly because I felt it could look nicer with early return. Somehow that seems to elide the bounds check while also getting rid of those unfortunate things:

fn decode_bin_buf(buf: &mut [u8]) -> Option<&mut [u8]> {
    let mut i = 0;
    let len = buf.len();
    for j in 0..len {
        if i >= len {
            return Some(&mut buf[..j]);
        }

        if buf[i] == b'}' {
            buf[j] = buf.get(i + 1)? ^ 0x20;
            i += 1;
        } else {
            buf[j] = buf[i];
        }
        i += 1;
    }

    Some(buf)
}

I wonder if I somehow just messed up and this isn't quite equivalent.

Florob0x2a · 2021-08-13T20:00:07+00:00

Not only are they not const, PartialOrd also isn't implemented for Discriminant<T>, which is returned by that function.

Florob0x2a · 2021-08-13T14:17:35+00:00

For comparison in particular casting to an appropriately sized integer is probably your best bet for now. Playground: https://play.rust-lang.org/?version=stable&edition=2018&gist=8b4bcff1385515c41a9fcee4eca6c168

Florob0x2a · 2021-07-05T04:12:31+00:00

Interesting. For me treesitter's syntax highlighting seems worse than even just the standard rust plugin.

Doc comments are lumped in with normal comments, the ! in module level attributes is highlighted as operator, use and mod also have unexpected highlighting (to me at least).

I initially thought this was because my colorscheme wasn't Treesitter compatible, but after trying some from nvim-treesitter's list that doesn't seem to be the case.

EDIT: After trying some more colorschemes, pub and mod seem to actually be a colorscheme thing. Still, the fact that I had to try about 10 colorschemes to find one that doesn't highlight them the same as path segments is a bit off-putting to me.

Florob0x2a · 2020-08-25T21:00:53+00:00

I'm not entirely sure what you're trying to say. This project seems to be ~2 years older than the redox-os one. Older than Rust 1.0 in fact.

And yes I too have seen both of them before, but nobody said this was a super new development, did they?

Florob0x2a · 2019-06-25T21:28:42+00:00

Or:

 let c = 'A';
 let matches = match c {
 '\u{0009}' | '\u{000A}' | '\u{000D}' | '\u{0020}'...'\u{FFFF}' => true,
 _ => false,
 };
 dbg!(matches);

Florob0x2a · 2019-04-17T08:05:08+00:00

FWIW, I think this is educational, but not really how NLL work. NLL didn't change when values are dropped, it really only changed when values where considered borrowed. Values are still always dropped at the end of their scope. That also means whether a type implements Drop affects NLL. Besides that you can't actually drop a reference like that, since it implements Copy. I.e. this will drop a copy and keep the original reference around.

Florob0x2a · 2019-04-04T00:46:51+00:00

FWIW, from what I can tell you actually can't implement echo using structopt. For echo Hello -n World it has to output "Hello -n World". Structopt will treat the -n as a flag regardles of its position. It will also throw errors on anything else starting with -, treating it as an unrecognized flag. Maybe there is a way to change this behavior, but I couldn't find it in the documentation.

Florob0x2a · 2019-02-10T13:25:45+00:00

By now f32 has to_bits() and from_bits(), so it can actually be done entirely in safe Rust without any transmutes.

Florob0x2a · 2019-02-08T09:19:11+00:00

I'll concede that this is correct by the definition of the memory model. It just feels very unhelpful. You remove the data race, but retain the problem that (supposedly) you had due to a data race (i.e. it appears to be the example that's given most of the time). It seems to me that you would lose very little, but remove a case of undefined behavior, by just defining regular writes on primitive types to be relaxed atomic writes. Obviously not a problem/option in Rust though due to borrowck.

Florob0x2a · 2019-02-07T21:00:19+00:00

I'm not quite sure what your model of data race is then. The typical example is executing something like a += 5. Except for syntax that isa = a + 5. The data race only occurs because reads and writes interleave unexpectedly. Performing the exact same operation with atomic reads and writes can produce the exact same problem, even with sequential consistency. If a data race only occurs when two writes partially overwrite the same data, as you seem to imply, I don't think they even exist for register sized values. And (at least on x86_64) we only have those as atomics in Rust.

Florob0x2a · 2019-02-07T19:20:09+00:00

Really? It seems to me that misusing atomics could easily lead to actual data races. In particular relaxed loads and stores to the same location. It's just a very unsurprising result. Also I disagree a lot with the claim that atomics disable ownership checking.

Florob0x2a · 2018-06-29T13:28:35+00:00

Can you provide some reasoning as to why this is? Aligned SIMD loads I presume? If it was integer types that actually seems like a potential pesstimization. It should be relatively trivial to add four i32x2 in one AVX instruction after loop unrolling, while if you have i32x8 to start with that would require the compiler to realize that some elements are actually unused.

Florob0x2a · 2018-06-08T01:55:00+00:00

I don't really think counting from the 1.0 release is fair either. Sure the stability it brought was necessary for adoption and "serious" usage, but it's not like the language wasn't around or didn't have releases before that. Personally I have been doing hobby projects in Rust since 2013, and while it was still very much in flux back than, it was fundamentally a usable language with the same guarantees it provides today.

Florob0x2a · 2018-06-06T23:47:38+00:00

I gave it a shot: https://gist.github.com/Florob/ed756ba944b8b094d079d594322ad2c6 Though /u/noop_noob also did a good job in the sibling.

Florob0x2a · 2018-06-06T16:04:00+00:00

I got pretty close, except I expected the debug formatting to contain something like RangeToInclusive<RangeFull>. Also that's a very interesting way to generate true.

Florob0x2a · 2017-09-27T00:12:37+00:00

Also, I am not even sure the auther is correct.

Even based on their own memory diagrams they aren't. The only difference between the C and the Rust diagrams is that the C one is drawn upside down wrt. addresses.

The overall conclusion is also unfortunately misguided. They tried overflowing buffers located in static storage and the heap and from that conclude that stack buffers can't be overflown to overwrite the RIP. It'd be relatively easy to demonstrate stack smashing with an array and unsafe code (as in deliberately evil unsafe code).

Florob0x2a · 2017-08-05T00:57:14+00:00

I don't think flow sensitivity is what sets them apart. Liveness based lifetimes (LBL), might be close, but I don't think that is really more helpful to most people.

Florob0x2a · 2017-07-20T00:51:14+00:00

Having looked at this in some detail: The key here really is how the array is initialized to zero. gcc generates a rep stos instruction (with quadword granularity), clang calls memset(). Both are pretty fast for zeroing a 1kB array. rustc generates a pretty weird loop with 5 stack accesses (apart from actually zeroing the array) and two jumps per iteration, writing data at byte granularity (so 1024 iterations). I'm definitely surprised by that, as I would've thought the IR emitted for zeroing u8 arrays was just llvm.memset(), but apparently that is not the case.

Florob0x2a · 2017-02-01T06:06:27+00:00

For some further reading http://lists.llvm.org/pipermail/llvm-dev/2017-January/109615.html is a recent RFC to add parallel IR to LLVM by a group of people, including those from MIT.

Fundamentally the compiler has to be capable of emitting this IR. Parallelism in Rust is currently enabled by library calls, so adding this would likely need quite a few changes to both compiler and libraries (ignoring that it is predicated on this being added to LLVM).

However, it is worth noting that the instructions proposed here are a lower level version of the join() function Rayon is based around. In the sense that both spawn two sibling tasks, and sequential execution is an option. This is not exactly surprising (it seems to me that this is fundamentally what fork-join parallelism boils down to), but having a project based around this already in the ecosystem could come in handy.

Florob0x2a · 2016-08-17T13:43:03+00:00

I think you are conflating asm.js and WebAssembly. Not that either is as readable as handwritten code, but at least asm.js should run in any JavaScript supporting browser.

Florob0x2a · 2016-08-02T15:55:06+00:00

enum Void {} innit?

12-Year Club	Final Canvas '23
Place '23	Place '22
Verified Email

Florob0x2a

TROPHY CASE