dtolnay

4 か月前議論

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 か月前議論

> 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 か月前議論

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

dtolnay

7 か月前議論

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 年前議論

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 年前議論

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 年前議論

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 年前議論

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 年前議論

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 年前議論

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 年前議論

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 年前議論

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 年前議論

https://archive.is/0OBYV

dtolnay

3 年前議論

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".

投稿

Emitting Safer Rust with C2Rust

コメント