dtolnay

4 months agodiscuss

If a piece of code does not panic in panic=unwind, then it does not panic in panic=abort either. So having coverage of panic=unwind would be sufficient to guarantee that code cannot panic. The caveat you mention with panic=abort would only apply to code that is unable to build for panic=unwind, which is uncommon.

dtolnay

4 months agodiscuss

> It's not a good option for library crates, e.g.

Author here. Yes, it is. It was literally made for libraries. Notably https://github.com/dtolnay/zmij and https://github.com/dtolnay/itoa use it to enforce that the libraries' public API is absent of panicking.

dtolnay

7 months agodiscuss

"1.e-01" is for 0.1, not 1.0.

dtolnay

7 months agodiscuss

In implementing Rust's serde_json library, I have dealt with both string-to-double and double-to-string. Of the two, I found string-to-double was more complex.

Unlike formatting, correct parsing involves high precision arithmetic.

Example: the IEEE 754 double closest to the exact value "0.1" is 7205759403792794*2^-56, which has an exact value of A (see below). The next higher IEEE 754 double has an exact value of C (see below). Exactly halfway between these values is B=(A+C)/2.

  A=0.1000000000000000055511151231257827021181583404541015625
  B=0.100000000000000012490009027033011079765856266021728515625
  C=0.10000000000000001942890293094023945741355419158935546875

So for correctness the algorithm needs the ability to distinguish the following extremely close values, because the first is closer to A (must parse to A) whereas the second is closer to C:

  0.1000000000000000124900090270330110797658562660217285156249
  0.1000000000000000124900090270330110797658562660217285156251

The problem of "string-to-double for the special case of strings produced by a good double-to-string algorithm" might be relatively easy compared to double-to-string, but correct string-to-double for arbitrarily big inputs is harder.

dtolnay

3 years agodiscuss

Try with http: http://blog.aaronballman.com/2023/12/musings-on-the-c-charte...

For me the original https link fails with "SSL received a record that exceeded the maximum permissible length. Error code: SSL_ERROR_RX_RECORD_TOO_LONG"

The http link redirected to safebrowse.io/warn.html where there is a "Proceed Anyway" link to get to the content.

dtolnay

3 years agodiscuss

The Information is cited as the source regarding the Google ad sales reorg. That would be this article from last week: https://www.theinformation.com/articles/google-plans-ad-sale...

dtolnay

3 years agodiscuss

The best forecast I know is Sean Parent's on ADSP episode 160.

[0:23:57] SP: We're also discussing internally around pending legislation around safety and security, what Adobe's response is going to be. Right now our thinking is we would like to publish a roadmap on how we're going to address that. That is not finalized yet in any form, but I expect a component of that roadmap is going to be that some of our critical components will get rewritten into Rust or another memory-safe language.

[0:24:28] CH: When you say "pending legislation", is that a nod to some pending legislation that you actually know is on the horizon? Or just anticipating that it's going to happen at some point?

[0:24:38] SP: Oh yeah, no. There are two bills (sorry I don't have...)

[0:24:44] CH: It's all right, we'll find them and link them in the show notes afterward.

[0:24:48] SP: Yeah, I can hunt down the links. The one in the U.S. that's pending basically says that the Department of Defense is going to within 270 days of the bill passing (and it's a funding bill which means it will probably pass late this year - early next year) that the Department of Defense will establish guidelines around safety and security including memory safety for software products purchased by Department of Defense. The E.U. has a similar wording in a bill that's slowly winding its way through their channels. I don't have insight into when that will pass. The U.S. one will almost certainly pass here within a month or two.

[0:25:43] CH: Oh. Wow.

[0:25:44] SP: There's a long way between having a bill pass that says almost a year later they have to establish a plan for what they're going to do, right. So it's not hard legislation in any way. But I view this-- I can send you a link. There was a podcast I listened to recently on macOS folklore. [...] It's talking about how in the early '90s there was a somewhat similar round of legislation that went around around POSIX compliance. Basically the Department of Defense decided that in order to have portable software, every operating system that they purchased had to have POSIX compliance. And there was a roadmap put into place. That's why Apple pursued building their own UNIX which was A/UX and eventually partnered with IBM to do AIX. And Microsoft in the same timeframe had a big push to get POSIX compliance in Windows OS. The thinking was eventually in order to sell to the government your operating system it would require POSIX compliance. What actually happened, if you wanted to buy just traditional Macintosh operating system you would just say "well I require Photoshop or pick-your-application and there is no alternative that runs under UNIX so therefore I need an exception to buy macOS" and it was extra paperwork but it got signed off on. So really never materialized into hard restrictions on sales of non-POSIX-compliant OSes. I expect the safety legislation to take somewhat the same route, which is, there will be pressure to write more software in memory-safe languages. When you don't write software in memory-safe languages there is going to be more pressure for you to document what your process is to mitigate the risks. And this is initially all in the realm of government sales, although there is some discussion in both the E.U. legislation and on the U.S. side of extending this to a consumer safety issue. But there will be an escape hatch because you couldn't wave any kind of magic wand as a legislator and say "you can't sell software anymore if it's written in C++". The world would grind to a halt. So there will be an escape hatch, and there will be pressure. So as a company you have to look at how are you going to mitigate that risk going forward. And what's your plan going to be so that you can continue to sell products to the government. And how do you make sure that you're not opening up a competitive threat. If you've got a competitor that can say "well we're written entirely in Rust so we don't have to do the paperwork" that becomes a faster path. So you want to make sure that you're aware of those issues and that you've got a plan in place to mitigate them.

dtolnay

3 years agodiscuss

Here is the gallery of finished pieces in the artist's shop: https://orbixhotglass.com/product-category/prince-ruperts-dr...

I am quite sure I saw #01 at $10k earlier today and it's now higher, so I suspect he found out he initially misjudged what Destin's advice of "priced not to sell" would need to mean.

dtolnay

3 years agodiscuss

I think about pull requests the same way:

As a library maintainer, closing and empathetically conveying why a pull request is not a net benefit to the project is an order of magnitude more effort than what it takes to throw up not-well-motivated pull requests on someone else's project.

dtolnay

3 years agodiscuss

Not automatic, but it already supports a measure of "how much" you depend on a project: boosting. You can boost dependencies up or down by up to a factor of 20 (e^3).

The formula is explained in https://thanks.dev/static/how.

dtolnay

3 years agodiscuss

Currently 2863 crates (2.6% of crates).

Note that the search you linked also includes crates that only have "rust" in the description or readme, not just the crate name -- that is why it shows a much higher count.

dtolnay

3 years agodiscuss

I have a non-toy multi-language project in https://github.com/dtolnay/cxx for which I have both Buck2 and Bazel build rules.

On my machine `buck2 clean && time buck2 build :cxx` takes 6.2 seconds.

`bazel clean && time bazel build :cxx` takes 19.9 seconds.

dtolnay

3 years agodiscuss

https://archive.is/0OBYV

dtolnay

3 years agodiscuss

I interpreted the author's characterization to be about something like:

  1  if (argc <= 2)
  2    puts("A");
  3  puts("B");
  4  if (argc <= 2)
  5    unreachable();
  6  else
  7    return puts("C");
  8  return puts("D");

in which not just lines 4-6,8 go away (as you said) but also lines 1-2.

It makes sense to me but I can see why the author would characterize this situation as "license to use an unreachable annotation on one code path to justify removing an entirely different code path that is not marked unreachable". In a different world one might expect A to be printed "before the UB happens".

dtolnay

4 years agodiscuss

See the explanation by the thanks.dev founder (qwerki) here: https://news.ycombinator.com/item?id=33368045

dtolnay

4 years agodiscuss

NPM has an order of magnitude more packages than the other language-specific package registries. It has more packages than every other registry put together (including Maven Central, PyPI, crates.io, etc).

http://www.modulecounts.com

dtolnay

4 years agodiscuss

https://thanks.dev has a good model for this. By default they'll split your monthly contribution equally among your dependencies (and exponentially decaying among transitive dependencies) but you can go in and "boost" or "unboost" specific dependencies or developers by up to a factor of 20 up or down. So if I have 2 dependencies which are equally important to my project but one is vastly higher effort to maintain, I can reflect that in the allocation.

dtolnay

4 years agodiscuss

I used it with great success for transpiring libyaml from C to Rust. I even set up Miri to run the upstream library's entire transpiled test suite, and the fact it passes is validation of absence of UB in the original C code.

The transpiled library now serves as the YAML backend for the widely used serde_yaml crate. Having serde_yaml be pure-Rust code instead of linking C is advantageous for painless cross-compilation as well as making downstream projects runnable in Miri.

https://github.com/dtolnay/unsafe-libyaml

dtolnay

4 years agodiscuss

Seems like it would be better to contain:

    compile_error!("You meant to …");

so that the install would fail and `cargo uninstall rg` wouldn't be needed.

dtolnay

4 years agodiscuss

> the minute you want to do something that doesn't fit the mold, it makes things a lot harder

This is not my experience at all; it's been extremely helpful for doing things outside the mold:

In a work codebase that is millions of lines of first-party Rust code with thousands of third-party Rust dependencies from crates.io, we're building with Buck not Cargo because that is what the rest of the monorepo uses for C++ and other languages. It's fantastic for this that all the third-party projects describe their dependency graph in the same standard Cargo manifest format and follow a standard project layout, even though our builds do not use Cargo, because we can programmatically translate them to Buck targets.

Submissions

Emitting Safer Rust with C2Rust

comments