Readit News logoReadit News

Deleted Comment

ChrisSD commented on Demoting i686-PC-windows-gnu to Tier 2   blog.rust-lang.org/2025/0... · Posted by u/ingve
wging · 3 months ago
Does that end up meaning, in practice, that stable releases are never broken, but nightly might be, for a tier 2 target?
ChrisSD · 3 months ago
More or less, yes. It is guaranteed that tier 2 at least builds so they'll be a nightly available every day though it's possible they might have a serious bug. To be honest though that's always a risk for nightlies even with tier 1 targets. Tests don't catch every potential problem (even if they do catch a lot) which is why there is a beta period before a release.
ChrisSD commented on Demoting i686-PC-windows-gnu to Tier 2   blog.rust-lang.org/2025/0... · Posted by u/ingve
wtallis · 3 months ago
Yes, only the 32-bit target, and only the gnu toolchain. Compiling on Windows using the Microsoft toolchain to target 32-bit Windows will still be on the Tier 1 list: https://doc.rust-lang.org/rustc/platform-support.html

Interestingly, Windows on ARM hasn't made it up to Tier 1 yet.

ChrisSD · 3 months ago
To be clear, tier 2 targets are still expected to be well supported. It just doesn't require CI to pass after every PR (meaning PRs aren't blocked on fixing tier 2 specific issues). However, the target is officially distributed and target maintainers are still expected to fix any blocking issues before a release. If they can't then it's likely the target will be demoted to tier 3.

Windows on ARM couldn't be tier 1 until recently as there weren't Windows ARM github runners. Now that there are I think it likely that it'll be promoted to tier 1.

ChrisSD commented on Bloat is still software's biggest vulnerability (2024)   spectrum.ieee.org/lean-so... · Posted by u/kristianp
GuB-42 · 4 months ago
I am beginning to think that the terrible situation with dependency management in traditional C and C++ is a good thing.

Now, with systems like npm, maven or cargo, all you need to do to get a package is to add a line in a configuration file, and it fetches all the dependencies you need automatically from a central repository. Very convenient, however, you can quickly find yourself with 100+ packages from who knows where and 100s of MB of code.

In C, traditionally, every library you include requires some consideration. There is no auto-download, and the library the user has may be a different version from the one you worked with, and you have to accommodate it, and so does the library publisher. Or you may have to ship is with your own code. Anyways, it is so messy that the simplest solution is often not to use a library at all and write the thing yourself, or even better, realize that you don't need the feature you would have used that library for.

Bad reason, and reinventing the wheel comes with its own set of problems, but at least, the resulting code is of a manageable size.

ChrisSD · 4 months ago
In my experience every developer, company, team, sub-team, etc has their own "library" of random functions, utilities, classes, etc that just end up being included into new projects sooner or later (and everyone and their dog has their own bespoke string handling libraries). Copy/pasting large chunks of code from elsewhere is also rampant.

I'm not so sure C/C++ solves the actual problem. Only sweeps it under a carpet so it's much less visible.

ChrisSD commented on Problems with Go channels (2016)   jtolio.com/2016/03/go-cha... · Posted by u/mpweiher
LtWorf · 4 months ago
What you think is not very relevant if it doesn't match how CPUs work.
ChrisSD · 4 months ago
huh?
ChrisSD commented on Problems with Go channels (2016)   jtolio.com/2016/03/go-cha... · Posted by u/mpweiher
t8sr · 4 months ago
When I did my 20% on Go at Google, about 10 years ago, we already had a semi-formal rule that channels must not appear in exported function signatures. It turns out that using CSP in any large, complex codebase is asking for trouble, and that this is true even about projects where members of the core Go team did the CSP.

If you take enough steps back and really think about it, the only synchronization primitive that exists is a futex (and maybe atomics). Everything else is an abstraction of some kind. If you're really determined, you can build anything out of anything. That doesn't mean it's always a good idea.

Looking back, I'd say channels are far superior to condition variables as a synchronized cross-thread communication mechanism - when I use them these days, it's mostly for that. Locks (mutexes) are really performant and easy to understand and generally better for mutual exclusion. (It's in the name!)

ChrisSD · 4 months ago
I think the two basic synchronisation primitives are atomics and thread parking. Atomics allow you to share data between two or more concurrently running threads whereas parking allows you to control which threads are running concurrently. Whatever low-level primitives the OS provides (such as futexes) is more an implementation detail.

I would tentatively make the claim that channels (in the abstract) are at heart an interface rather than a type of synchronisation per se. They can be implemented using Mutexes, pure atomics (if each message is a single integer) or any number of different ways.

Of course, any specific implementation of a channel will have trade-offs. Some more so than others.

ChrisSD commented on C stdlib isn't threadsafe and even safe Rust didn't save us   edgedb.com/blog/c-stdlib-... · Posted by u/msully4321
wahern · 7 months ago
libc does do locking, but it's insufficient. The semantics of getenv/setenv/putenv just aren't safe for multi-threaded mutation, period, because the addresses are exposed. It's not really even a C language issue; were you to design a thread-safe env API, for C or Rust, it would look much different, likely relying on string copying even on reads rather than passing strings by reference (reference counted immutable strings would work, too, but is probably too heavy handed), and definitely not exposing the environ array.

The closest libc can get to MT safety is to never deallocate an environment string or an environ array. Solaris does this--if you continually add new variables with setenv it just leaks environ array memory, or if you continually overwrite a key it just leaks the old value. (IIRC, glibc is halfway there.) But even then it still requires the application to abstain from doing crazy stuff, like modifying the strings you get back from getenv. NetBSD tried adding safer interfaces, like getenv_r, but it's ultimately insufficient to meaningfully address the problem.

The right answer for safe, portable programs is to not mutate the environment once you go multi-threaded, or even better just treat process environment as immutable once you enter your main loop or otherwise finish with initial process setup. glibc could (and maybe should) fully adopt the Solaris solution (currently, IIRC, glibc leaks env strings but not environ arrays), but if applications are using the environment variable table as a global, shared, mutable key-value store, then leaking memory probably isn't what they want, either. Either way, the best solution is to stop treating it as mutable.

ChrisSD · 7 months ago
A safe API would look a lot like Windows' GetEnvironmentVariable and SetEnvironmentVariable

https://learn.microsoft.com/en-us/windows/win32/api/winbase/...

https://learn.microsoft.com/en-us/windows/win32/api/winbase/...

ChrisSD commented on C stdlib isn't threadsafe and even safe Rust didn't save us   edgedb.com/blog/c-stdlib-... · Posted by u/msully4321
Thaxll · 7 months ago
Why requiring unsafe when the std implementation could take care of the synchronisation?
ChrisSD · 7 months ago
It can only synchronize if everything using is Rust's functions. But that's not a given. People can use C libraries (especially libc) which won't be aware of Rust's locks. Or they could even use a high level runtime with its own locking but then they'll be distinct from Rust's locks.

The only way to coordinate locking would be to do so in libc itself.

ChrisSD commented on C stdlib isn't threadsafe and even safe Rust didn't save us   edgedb.com/blog/c-stdlib-... · Posted by u/msully4321
ChrisSD · 7 months ago
In the Rust std, `set_var` and `remove_var` will correctly require using an `unsafe {}` block in the next edition (2024). The documentation does now mention the safety issue but obviously it was a mistake to make these functions safe originally (albeit a mistake even higher level languages have made).

https://doc.rust-lang.org/stable/std/env/fn.set_var.html

There is a patch for glibc which makes `getenv` safe in more cases where the environment is modified but C still allows direct access to the environ so it can't be completely safe in the face of modification https://github.com/bminor/glibc/commit/7a61e7f557a97ab597d6f...

ChrisSD commented on WorstFit: Unveiling Hidden Transformers in Windows ANSI   blog.orange.tw/posts/2025... · Posted by u/notmine1337
okanat · 7 months ago
What about the entry point? Because one of the issues mentioned in the article is about mainCRTStartup calling an ANSI API. Most of the Rust programs are linked with the C runtime. Does Rust make sure that the C library initialization is also done in Unicode APIs?
ChrisSD · 7 months ago
No but it doesn't use C library values so it doesn't matter. E.g. getting the command line arguments is done via calling `GetCommandLineW` so it doesn't use argv or argc.

This is actually necessary because Rust cannot assume it owns the entry point. E.g. a Rust library could be called from a C++ application or in a DLL, etc. So when someone calls `std::env::args` it asks the OS directly for the arguments instead of getting them from C.

u/ChrisSD

KarmaCake day7137August 5, 2017
About
64b2ffe4-6461-4f2e-9258-2a1839d40720
View Original