[HN Gopher] Rust 1.59.0 with inline assembly support etc.
___________________________________________________________________
Rust 1.59.0 with inline assembly support etc.
Author : 0xedb
Score : 201 points
Date : 2022-02-24 17:07 UTC (5 hours ago)
(HTM) web link (blog.rust-lang.org)
(TXT) w3m dump (blog.rust-lang.org)
| benibela wrote:
| Inline assembly? Is that not too unsafe for Rust?
| josephcsible wrote:
| It's only usable in unsafe blocks.
| throwawayninja wrote:
| My favorite thing about rust is that it has no magic "don't
| look behind the curtain and your programs will be safe" guard -
| instead, you define the guard yourself; it's just unnecessary
| for 99% of code, and within the 1% where you are defining your
| own curtain the borrow checker et al still try to uphold
| outside guarantees, making it difficult to shoot _anything_
| besides the correct target with rust.
| pjmlp wrote:
| You can still get it wrong, careful with the advocacy.
|
| https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=rust
| littlestymaar wrote:
| You can still get it wrong, it's just way rarer. (95% of
| the CVEs listed here are simply "program can trigger UB",
| which in the C or C++ land isn't worth a CVE in itself)
| lijogdfljk wrote:
| I'd be curious to see how many of those are actually safe
| code though, eh? I've written hundreds of thousands of
| lines of Rust. Can we estimate how much UB i've introduced?
| tialaramex wrote:
| So let's take a closer look at the fairly recent
| CVE-2022-21658.
|
| Rust's standard library provides
| std::fs::remove_dir_all("/some/dir"), in C++ you will find
| the very similar std::filesystem::remove_all("/some/dir")
|
| As you might anticipate, these functions get rid of the
| directory /some/dir if necessary deleting sub-directories
| and files recursively in order to achieve that.
|
| They both explain that they won't delete other things, even
| if there's a symlink in /some/dir or some child that
| _points_ to those outside things, the symlink gets deleted
| but not the thing it pointed to.
|
| What kind of terrible unsafety was discovered in
| CVE-2022-21658?
|
| Until Rust 1.58.1 you could exploit a TOCTOU race condition
| to blow away other people's stuff using symlinks when they
| made this call.
|
| And where is the CVE for the same bug in C++? There isn't
| one. C++ standards people argued that the C++ standard
| already actually says that none of their filesystem API is
| safe to use if you have a "concurrent environment" in which
| such races are possible. Standard C++ programs are only
| intended to run on a machine where they have exclusive
| control over the entire system for the entire length of
| their runtime and so when your C++ program deletes files
| you thought it couldn't delete that was actually _your_
| fault for not being familiar with every caveat and ruling
| in the entire C++ standard.
|
| What should you do about that? I believe the answer is
| obvious: Use Rust
| rackjack wrote:
| `ControlFlow` is a nice QoL addition.
| ezekiel68 wrote:
| Good stuff in here. But since they found a bug which caused them
| to disable incremental compilation by default for this release,
| I'll likely skip this one and wait a few weeks for 1.60.0 (which
| these release notes state will likely address the problem and
| restore default incremental compilation)
| xiphias2 wrote:
| Isn't the best solution to stop the release in that case, and
| wait until the bug is fixed?
|
| It sends a signal to everybody that language correctness takes
| precedence over this extremely important feature that more
| developers depend on than the new features in the release,
| instead of treating the two with the same seriousness.
| DougBTX wrote:
| Have to say I've not been following this in any detail, but it
| was also disabled in 1.52.1, has it been re-enabled again in
| the meantime?
|
| https://blog.rust-lang.org/2021/05/10/Rust-1.52.1.html
| nicoburns wrote:
| Yes, it had. There have been ongoing minor bugs (most people
| won't hit them, and if they do they can just do a fresh
| build) which they've been fixing over time. But apparently
| some of the fixes exposed a worse bug this time around, and
| it wasn't caught until just before the release.
| black_puppydog wrote:
| Errrrr.... so you mean you'd rather have the bug, thank you
| very much? :) Why not just "export RUSTC_FORCE_INCREMENTAL=1"
| in your env and hope for the best then? :P
| kibwen wrote:
| Alternatively you can use Rust beta today: `rustup toolchain
| install beta && rustup default beta`. You'll be doing everyone
| a favor, as the fact that relatively few people use beta
| regularly is part of the reason that this issue didn't surface
| until the last minute. (Plenty of people use beta for CI, which
| is great, but CI obviously doesn't exercise incremental
| compilation).
| mrlonglong wrote:
| I really appreciated the inline ASM in the nightlies when doing a
| tutorial on working with the RISC-V architecture. Glad it's gone
| stable.
| ncmncm wrote:
| It was only a few years ago (2015?) that people asking for
| destructured assignment were treated like simpletons, with a
| long, jargon-laden explanation how the language formal syntax for
| destructured "let" was incompatible with assignment syntax as it
| was then, as if syntax were not something that could be extended
| anytime, or as if there would be no choice but to express it
| using the same nonterminals for both.
|
| Yet, here it is. I was not fooled, but the attitude left a deep
| impression.
| Arnavion wrote:
| Not mentioned, but the previous release's feature of capturing
| idents in format strings automatically did not work for
| `unreachable!`, ie `let x = 5; unreachable!("{x}");` panicked
| with the message `"{x}"` instead of `"5"`. This is fixed in 1.59
| exitcode0 wrote:
| Neat! Interestingly Ada has had this feature since its inception
| around 1983 (use in action with CPUID -
| https://gist.github.com/AdaDoom3/6466215).
| pjmlp wrote:
| It is nothing new, all high level systems programming languages
| used to have inline Assembly, and ESPOL in 1961 already had
| intrisics instead.
| Kelteseth wrote:
| > Today's release falls on the day in which the world's attention
| is captured by the sudden invasion of Ukraine by Putin's forces.
| Before going into the details of the new Rust release, we'd like
| to state that we stand in solidarity with the people of Ukraine
| and express our support for all people affected by this conflict.
| dthul wrote:
| Really looking forward to const generics becoming more and more
| useful in the future! A current limitation I hit yesterday is
| that you can't use a (non-literal) expression as a const generic
| parameter yet. I wanted to specify 32KiB as "32 * 1024" but had
| to write "32768" instead.
| nynx wrote:
| You can use constant expressions in const generics in many
| cases.
|
| https://play.rust-lang.org/?version=stable&mode=debug&editio...
| dthul wrote:
| Thanks! I didn't realize that it required curly braces and
| only went off of the red squiggly line my IDE put there
| instead of reading the helpful compiler output.
| rhn_mk1 wrote:
| I'm always hitting the limitation that I can't use a const
| parameter on a trait like a const generic. As an example, this
| is disallowed:
|
| struct Helper<B: Buffer> { x: [u8; B::SIZE], }
| tikkabhuna wrote:
| Very much a rust newbie. What is this syntax called?
|
| > inout(reg) a,
|
| inout looks like a function but I don't see how that works with
| the `a` variable. Is this some magic specifically for asm!?
| yberreby wrote:
| This is specific to asm!. It is a macro, and you can use macros
| to implement custom syntactic constructs.
| tikkabhuna wrote:
| Thanks! I'll have to take a look at the Macros section of the
| book.
| tiddles wrote:
| Glad to see inline asm is finally stabilised, that's one less
| reason to use nightly for osdev!
| josephcsible wrote:
| Does asm! now give you as much power as llvm_asm! did? I
| remember a while ago that there were some constructs only
| possible with the latter.
| jcranmer wrote:
| So asm! is basically the same functionality, except it's been
| stripped down to features that are more easily verified for
| correctness, and some of the syntax has been tweaked to be
| more understandable. The original asm! macro just passed
| everything through to the LLVM inline asm construct in raw
| form, and was renamed llvm_asm! to allow people to keep
| compatibility while the cleaned-up version of asm! was worked
| on.
|
| I think the biggest missing features are the more exotic,
| non-register constraints, but some of the reasons those are
| omitted are because of unclear coordination between Rust code
| and the assembly language string.
| kibwen wrote:
| Can you give more specifics? Backend-wise, the new asm
| support is still using LLVM's assembly facilities, so it
| should be just as capable. As far as the user-facing portion
| is concerned, some features of the `asm!` macro are still
| unstable (most notably const operands and sym operands), but
| I'm not aware of any feature that doesn't have an equivalent.
| kibwen wrote:
| And support for the `#[naked]` attribute will likely be
| stabilizing within the next few months (source: I'm getting
| sponsored to work on it), allowing one to write functions that
| have precise control over the stack, which is useful for
| interrupt handlers.
| eddyb wrote:
| Don't you want "interrupt ABIs" for that specific usecase?
|
| IIRC `#[naked]` are only really guaranteed to allow inline
| assembly, so it's like defining a function in `global_asm!`
| except for monomorphization and generally interfacing better
| with the rest of the language.
___________________________________________________________________
(page generated 2022-02-24 23:01 UTC)