robinm

joined 1 year ago
[–] robinm@programming.dev 1 points 12 hours ago

That's why I did not said it was impossible, just order of magnitude harder to catch in C++ compared to Rust.

To have asan finding the bug, you need to have a valid unit test, that has a similar enough workload. Otherwise you may not see the bug with asan if the vector doesn't grow (and thus ref would still be valid, not triggering UB), leading to a production-only bug.

Asan is a wonderfull tool, but you can't deny it's much harder to use and much less reliable than just running your compiler.

[–] robinm@programming.dev 1 points 19 hours ago (2 children)
void foo() {
    std::vector v = {0, 1, 2, 4};
    const auto& ref = v[1];
    add_missing_values(v);
    std::cout << ref << "\n";
}

void add_missing_values(std::vector<int>& v) {
    // ...
    v.push_back(3);
}

Neither foo(), nor add_missing_values() looks suspicious. Nonetheless, if v.push_back(3) requires v to grow, then ref becomes an invalid reference and std::cout << ref becomes UB (use after free). In Rust this would not compiles.

It is order of magnitudes easier to have lifetime errors in C++ than in Rust (use after free, double free, data races, use before initialisation, …)

[–] robinm@programming.dev 1 points 5 days ago (4 children)

Is it possible to do in Rust?

Yes

Is possible to do in Rust, by mistake, and not easily caught by a review?

Definitively not.

[–] robinm@programming.dev 1 points 2 weeks ago

DRY and YAGNI are awesome iif you also practice YNIRN (You Need It Right Now)! Otherwise you just get boilerplate of spaghetti

[–] robinm@programming.dev 27 points 1 month ago

You got me in the first 3 quarters, not gonna lie!

[–] robinm@programming.dev 1 points 1 month ago

There are cases where instead of origin/master..HEAD you may want to use @{upstream}..HEAD instead to compare with the upstream of your current branch. It's unfortunately quite unknown.

[–] robinm@programming.dev 1 points 4 months ago

The quote (and the associated discussion) is such an important part of Rust and why I love this language so much. Anything that can be automated should at one point be automated reliably, and the sooner the better.

[–] robinm@programming.dev 7 points 6 months ago

Thank you! I didn’t realized that I was using my lemmy account and not my mastodon account.

 

Hello,

I’m trying to follow Lennard Poetting (@pid_eins@mastodon.social) from my programming.dev account without success.

On its user profile on mastodon.social, when I click on the “follow” button, then enter “programming.dev” (which is in the completion list) then “take me home”, I am redirected to https://programming.dev/authorize_interaction?uri=https%3A%2F%2Fmastodon.social%2Fusers%2Fpid_eins which is a 404 error.

I also tried to search for “@pid_eins@mastodon.social” directly from programming.dev, found it, but 0 toot, and no button to be able to follow it.

Am I doing something wrong? Is mastodon.social and programming.dev not federated?

[–] robinm@programming.dev 1 points 8 months ago (1 children)

I wasn't clear enough. But in a contry where the sun rise at 20:00, the weekday looks like:

  • day 1: Monday morning to Tuesday evening
  • day 2: Tuesday morning to Wednesday evening
  • day 3: Wednesday morning to Thurday,

And phares like "let's meet on Tuesday“ without hour indication could either mean end of day 1 or start of day 2. Likewise "let's meet the 20th” (assuming the 20th is a Tuesday) could either mean end of day 1 or beggining of day 2.

--

And alternative be to have

  • day 1 == Monday == “end of the 19th” to “the start of the 20th”
  • day 2 == Tuesday == “end of the 20th” to “the start of the 21st”
  • day 3 == Monday == “end of the 21st” to “the start of the 22nd”

Which solve the issue of "let's meet on Tuesday”, but not “let's meet the 20th”.

[–] robinm@programming.dev 5 points 8 months ago (4 children)

The issue is that the notion of "tomorrow" becomes quite hard to express. If it’s 20:00 when the sun rose, when does tomorrow starts? In 5 hours ?

[–] robinm@programming.dev 2 points 9 months ago

Interesting idea indeed. I've never used async yet, but I'm always surprised at how the problem space seems to be much more complicated than what it initially looks like.

[–] robinm@programming.dev 8 points 9 months ago (1 children)

You shouldn't, it's short and interesting

 

The Rust for Linux (RFL) project may not have (yet) resulted in user-visible changes to the Linux kernel, but it seems the wider world has taken notice. Hongyu Li has announced that the Rust for Linux code is now part of a satellite just launched out of China. The satellite is running a system called RROS, which follows the old RTLinux pattern of running a realtime kernel alongside Linux. The realtime core is written in Rust, using the RFL groundwork.

Despite its imperfections, we still want to share RROS with the community, showcasing our serious commitment to using RFL for substantial projects and contributing to the community's growth. Our development journey with RROS has been greatly enriched by the support and knowledge from the RFL community. We also have received invaluable assistance from enthusiastic forks here, especially when addressing issues related to safety abstraction

(Thanks to Dirk Behme).

view more: next ›