arendjr

That’s entirely dependent on the application. In many cases the command would be hard-coded in the application, in which case you’re right. But some applications have good reasons to pass user-supplied arguments to scripts. Imagine a case where an application generates PDFs through a batch script, for instance. It might make sense to let users specify the filename, but then it does need proper escaping. In such a case it’s a huge risk if it turns out the escaping rules suddenly changed because Windows silently invoked cmd.exe under the hood.

It’s a bit arguing about semantics really. But Rust and Haskell are merely the first ones with patches out. The issue affects other languages as well, including Java, Node.js, Python and seemingly every language with Windows support. I think it’s fair to call it a Windows problem, since it affects everyone there.

But languages like Rust and Haskell are promising their users that they are protected from this kind of behavior, which is why they want to patch it quickly. Some of the others merely updated the documentation, effectively saying yeah it’s a risk. Java went as far as saying they won’t fix the issue.

It also seems harsh to say iterators aren’t a zero-cost abstraction if they miss an optimisation that falls outside what the API promises. It’s natural to expect collect to allocate, no?

You're right, I wouldn't say iterators aren't a zero-cost abstraction. But most abstractions are also leaky -- it's just the extent in which the leakiness is exposed that makes them more or less effective. As such, saying to just use retain_mut instead of the iterator approach highlights the shortcoming of the abstraction. But if the same results could be achieved while still using the same iterator, that would make that abstraction more useful and consistent. And that's great, because that means we need to worry less when using iterators :)

The composability doesn't have much to do with whether it's a reference or a move, it's because it bypasses usage of the Iterator methods. Iterators chains can consist of filter, map and other operations, which allows various functions and/or closures to be composed together. Whereas with retain_mut() there isn't really a chain and functions you may otherwise use in an iterator chain become harder to (re)use.

Thanks! That’s very much what I was looking for!

That was a super interesting and informative read! Exactly what I was hoping to find when I posted this, thanks!

Yeah, that's helpful if I would be currently optimizing a hot loop now. But I was really just using it as an example. Also, retain_mut() doesn't compose as well.

I'd much rather write:

let vec_a: Vec<String> = /* ... */;
let vec_b: Vec<String> = vec_a
    .into_iter()
    .filter(some_filter)
    .map(some_map_fn)
    .collect();

Over:

let mut vec_a: Vec<String> = /* ... */;
vec_a.retain_mut(|x| if some_filter(x) {
    *x = some_map_fn(*x); // Yikes, cannot move out of reference.
    true
} else {
    false
});

And it would be nice if that would be optimized the same. After all, the point of Rust's iterators is to provide zero-cost abstractions. In my opinion, functions like retain_mut() represent a leakiness to that abstraction, because the alternative turns out to not be zero cost.

I mean, the actual operation is just an example, of course. Feel free to make it a .map() operation instead. The strings couldn’t be reused then, but the vector’s allocation still could… in theory.

That’s certainly not the case, because that’s like saying the issue is with Rust’s string slices. I think you may have missed the part of the issue where batch scripts require additional escaping due to Windows’ command handling. It’s a ridiculous design of the Windows API system, which is also why (almost?) every language they tested was vulnerable, so it would be actually very outstanding if Qt prevented this.

For C++ devs not using Qt it’s just another footgun they’ll likely keep introducing security issues with as well. But if you do use Qt, I think it’s better to double-check since it may also require a patch.

What are the chances Qt is affected by this issue too?

I think they meant using for accumulating, like this:

shapes.iter().map(Shape::area).sum()

Usually your coroutines (should) all spin up at the very start and all stay running for the entire app lifetime.

That’s an interesting perspective. At that point, what is even the point of coroutines over using threads? I thought the main reason for their existence was being lightweight enough to spin up whenever, wherever you need.