I found this funny.
The context is as explained by @laund@hachyderm.io
the issue is that you can’t return from inside a closure, since the closure might be called later/elsewhere
and this post was the asnwer to the question by @antonok@fosstodon.org
you got me curious what the record for the longest
?operator chain on crates.io is
Original post: https://fosstodon.org/users/antonok/statuses/111134824451525448
I think the issue with this is that the code (https://docs.rs/nix/0.27.1/src/nix/lib.rs.html#297) allocates a fixed-size buffer on the stack in order to add a terminating zero to the end of the path copied into it. So it just gives you a reference into that buffer, which can’t outlive the function call.
They do also have a
with_nix_path_allocatingfunction (https://docs.rs/nix/0.27.1/src/nix/lib.rs.html#332) that just gives you aCStringthat owns its buffer on the heap, so there must be some reason why they went this design. Maybe premature optimization? Maybe it actually makes a difference? 🤔They could have just returned the buffer via some wrapper that owns it and has the
as_cstrfunction on it, but that would have resulted in a copy, so I’m not sure if it would have still achieved what they are trying to achieve here. I wonder if they ran some benchmarks on all this stuff, or they’re just writing what they think will be fast.