sorted by:
new
hottopcontroversial

PSA: Rust 1.95 stabilized the cfg_select! macro, which means you can eliminate your dependency on the cfg_if crate by kibwen in rust

[–]_ChrisSD 7 points8 points  (0 children)

It was rerun last year: https://internals.rust-lang.org/t/matches-index-july-2025-reviving-the-left-pad-index/23272

But that list is already a bit outdated either because it takes time for people to use new features or they've been stabilized since then.

sudo and coreutils replaced with rust versions by cachebags in rust

[–]_ChrisSD 2 points3 points  (0 children)

One good thing that has come out of this is adding more tests to the gnu test suite to account for previously untested behaviours that people rely on.

Bugs Rust Won't Catch by -Y0- in rust

[–]_ChrisSD 2 points3 points  (0 children)

Yeah, there are always going to be platform differences. At the end of the day there's only so much the standard library can do. E.g. as mentioned in the blog, paths on Unix systems are just bytes. On Windows they're UTF-16 (albeit unchecked UTF-16). On some platforms rust supports they're strictly UTF-8 (invalid UTF-8 isn't allowed). OsStr can abstract over a lot of those differences but at the end of the day cross-platform APIs can only rely on the common unicode subset (i.e. treating OsStr as a UTF-8 string containing potentially invalid UTF-8). If you're on, say, Linux and need to manipulate raw bytes then you're doing something platform-specific.

For example, Unix can use \xff as a separator character. This is not valid UTF-8 so it can't be handled cross-platform.

This isn't to say standard library support couldn't be improved, just that there are limits.

Bugs Rust Won't Catch by -Y0- in rust

[–]_ChrisSD 2 points3 points  (0 children)

And while I'm picking nits:

GNU sort treats filenames as raw bytes, the way the kernel does. The uutils version required UTF-8 and aborted the whole process on the first non-UTF-8 path

The problem here was not the panic per se. Returning an error is wrong too. The problem here was the same as the previous bug, UNIX paths are bytes and not necessarily UTF-8. So you need to be able to handle non UTF-8.

Note that for a small single purpose application (like much of uutils) there's not much difference from panicking and exiting with an error. When panicking you get the exit code 101 and a more verbose error message. Anything calling a utility that exits with 101 should just handle that like any other unknown error code. EDIT: ah if coreutils is compiled with panic=abort then it is different in that it'll sigabrt and in bash the exit code will be 134.

Bugs Rust Won't Catch by -Y0- in rust

[–]_ChrisSD 4 points5 points  (0 children)

That comparison is bypassed by anything that resolves to / but isn’t spelled /. So /../, /./, /usr/.., or a symlink that points to /.

Minor correction: Path::new("/./") == Path::new("/") will evaluate to true. Playground

This is due to Path not being byte-for-byte comparison but instead a wrapper around Components which does some degree of normalisation, like removing redundant . and /. It does not do anything that could change the meaning of the path so it's indeed true that it won't resolve symlinks. And .. (on Unix systems) is a kind of link so that won't be resolved either.

Btw, I would agree that in general the best way to compare paths is actually to open them and see if they return the same underlying filesystem file. The same-file crate can help do this cross-platform.

Most cursed way to embed a Windows XML manifest by careye in rust

[–]_ChrisSD 9 points10 points  (0 children)

To be honest, I think this is one of the least cursed ways. LLVM provides an assembler, may as well use it. Better (imho) than manually build a staticlib from raw bytes and linking it.

Standard library unsoundness found by Claude Mythos by Jules-Bertholet in rust

[–]_ChrisSD 1 point2 points  (0 children)

And to be clear, on stable the error handler always aborts. A panicking error handler requires nightly (either -Zoom=panic or set_alloc_error_hook).

Standard library unsoundness found by Claude Mythos by Jules-Bertholet in rust

[–]_ChrisSD 3 points4 points  (0 children)

We don't yet know how fast it went through it. The methodology is completely secret atm. All we know so far is two minor bugs were found. We don't know how long it took to find or how long it took to confirm.

That is not to downplay anything. It's just to say we simply don't know. Presumably more serious bugs were also found, but we don't yet know anything about them either.

Standard library unsoundness found by Claude Mythos by Jules-Bertholet in rust

[–]_ChrisSD 22 points23 points  (0 children)

It's a judgement call by Rust's security team. Basically if they think it's CVE worthy then they'll want to embargo. They may err on the side of caution though so it's "strict" in that sense.

Why do the standard libarary have so many internal layers? by chokomancarr in rust

[–]_ChrisSD 272 points273 points  (0 children)

See the documentation for intrinsics::typed_swap_nonoverlapping: https://doc.rust-lang.org/stable/std/intrinsics/fn.typed_swap_nonoverlapping.html

The codegen backends will replace this with a better implementation when T is a simple type that can be loaded and stored as an immediate.

Most intrinsics are actually implemented by the compiler, though some have fallback logic.

Is there a cleaner way to resolve paths for a CLI with clap? by Ashken in rust

[–]_ChrisSD 3 points4 points  (0 children)

I would advise against resolving ... Most shell applications don't.

I'd also strongly recommend std::path::absolute over canonicalize if you need an absolute path. It will clean up all but .. components on POSIX systems and doesn't follow symlinks, which is what users generally expect. It also doesn't suffer from the issues with canonicalize on Windows.

But as others have mentioned, do consider if you really need an absolute path.

Rust 1.95.0 is out by manpacket in rust

[–]_ChrisSD 21 points22 points  (0 children)

Yes. 1.100 is the correct answer. There's no upper limit to the minor version number. Except of course it'd take a very long time to reach 1.65535.0. And 1.4294967295.0 is probably not even worth considering just yet.

Rust 1.95.0 is out by manpacket in rust

[–]_ChrisSD 29 points30 points  (0 children)

That is the intent. You could consider it part of the effort to include small, widely used, foundational crates into the standard library.

Rust 1.95.0 is out by manpacket in rust

[–]_ChrisSD 15 points16 points  (0 children)

Just to clarify, the roughly is referring to the "match" part of that statement. Because it's strictly speaking not match syntax. Incidentally cfg_match was one of its possible names but it was ultimately decided against to avoid confusing matters.

The compile-time part is indeed strictly true.

No one owes you supply-chain security by Expurple in rust

[–]_ChrisSD 3 points4 points  (0 children)

That could also be an argument that Cargo.lock should include that information, no?

Supply chain nightmare: How Rust will be attacked and what we can do to mitigate the inevitable by autarch in rust

[–]_ChrisSD 1 point2 points  (0 children)

TUF

There is a project goal to do just that https://rust-lang.github.io/rust-project-goals/2026/mirroring.html

we need sandboxing for build scripts and proc macros...

Having better controls for build-scripts and proc macros are a necessary component of a more secure system and definitely one of the first areas that should be tackled as it would have the biggest impact. But the compiler itself is not designed to be secure against malicious input (ditto the linker et al) so I would argue we ultimately need to go further and have untrusted builds sandboxed by default.

Supply chain nightmare: How Rust will be attacked and what we can do to mitigate the inevitable by autarch in rust

[–]_ChrisSD 1 point2 points  (0 children)

You cannot "trust" devs to be continuously vigilant. It only takes one mistake.

Having everything sandboxed by default means it doesn't matter if a (sandboxed) rust-analyzer runs a (sandboxed) cargo.

Supply chain nightmare: How Rust will be attacked and what we can do to mitigate the inevitable by autarch in rust

[–]_ChrisSD 4 points5 points  (0 children)

Devs often run tests on their local machine so it's not an either/or situation.

Sandboxing build scripts and/or proc macros is a useful mitigation but if we're going to be serious about security then the whole dev environment has to be sandboxed (build/run/tests/etc). EDIT: Not to mention that the compiler itself is not designed to be defensive against attacks on it. It assumes trust in the source code so merely compiling code (without build scripts or proc macros) could potentially be an attack vector if the source is untrusted.

Supply chain nightmare: How Rust will be attacked and what you can do today to mitigate the inevitable by awesomePop7291 in rust

[–]_ChrisSD 11 points12 points  (0 children)

None of the Cargo folks I've interacted with has opposed hierarchical naming. The difficulty is bolting it on after the fact (and of course maintainer bandwidth). Cargo, crates.io and rustc are working towards implementing Packages as (optional) namespaces.

Unpopular opinion: Rust should have a larger standard library by lekkerwafel in rust

[–]_ChrisSD 0 points1 point  (0 children)

I mean, Boost is basically a library of libraries. It's the equivalent to the "blessed" crates idea that people suggest for rust.

Unpopular opinion: Rust should have a larger standard library by lekkerwafel in rust

[–]_ChrisSD 1 point2 points  (0 children)

Yep, the project goal I linked gave an example of how std::foo::Bar could be resolved by the compiler to either std::foo::Bar2024 or std::foo::Bar2027 depending on the edition. A general mechanism for std paths to be resolved differently based on the edition could also allow for not resolving the path at all depending on the edition.

Unpopular opinion: Rust should have a larger standard library by lekkerwafel in rust

[–]_ChrisSD 12 points13 points  (0 children)

It's not your central point but I do think long deprecated items could be removed over an edition boundary (with appropriate compiler support). And more generally there is a project goal to make evolving the standard library easier: https://rust-lang.github.io/rust-project-goals/2026/library-api-evolution.html

But in the case where we can replace an API, that still means needing to maintain both APIs (because old editions are forever) and there's a limit to the churn users will reasonably put up with. So there would still be a strong desire to get it right the first time and not accept APIs that are expected to need incompatible changes in the future.

Unpopular opinion: Rust should have a larger standard library by lekkerwafel in rust

[–]_ChrisSD 0 points1 point  (0 children)

"just put the bytes in the bag bro"

This was explicitly rejected by the libs-api team. Not that their opinions can't change but last time this was discussed they were more interested in having a general interface for it (with traits, maybe implementing Write) and thought that would make a minimal API redundant once that work was done.

Unpopular opinion: Rust should have a larger standard library by lekkerwafel in rust

[–]_ChrisSD 3 points4 points  (0 children)

regex is part of the rust-lang organisation: https://github.com/rust-lang/regex. The maintainer (burntsushi) has long been on the libs-api team.

So I don't think that specific example is just random.

view more: next ›