`core::net` soon to be stable! #1

New issue

Closed

opened 2024-02-13 07:48:38 +13:00 by faern · 3 comments

faern commented

2024-02-13 07:48:38 +13:00

(Migrated from github.com)

The core::net module is heading for stabilization. It's currently stable in beta and will be stable in the next stable Rust release (1.77) unless it's reverted for some reason. That's good news, because it means custom crates like this one won't be needed any longer to get basic network primitives in no_std.

In order to use these features, you probably will have to std::mem::transmute the types from the actual core library into these types and back. Have fun.

You might already be aware, but I'd highly recommend against this. Nothing guarantees that the memory layout of these types will be the same as the ones in core/std. Depending on what version of Rust the program is built against, it might contain invalid memory reads/writes. I realize this might actually come off as a "well actually..."-comment. I suspect this crate was created as a quick solution to an practical problem :)

The `core::net` module is heading for stabilization. It's currently stable in beta and will be stable in the next stable Rust release (1.77) unless it's reverted for some reason. That's good news, because it means custom crates like this one won't be needed any longer to get basic network primitives in `no_std`. > In order to use these features, you probably will have to `std::mem::transmute` the types from the actual core library into these types and back. Have fun. You might already be aware, but I'd highly recommend against this. Nothing guarantees that the memory layout of these types will be the same as the ones in `core`/`std`. Depending on what version of Rust the program is built against, it might contain invalid memory reads/writes. I realize this might actually come off as a "well actually..."-comment. I suspect this crate was created as a quick solution to an practical problem :)

mikedilger commented

2024-02-13 22:23:52 +13:00

(Migrated from github.com)

This is good to know.

Yes, it was a hack around using Ipv4Addr and Ipv6Addr to call .is_global(). Yes, the transmute is not at all future safe, I get the point. Since I published this to crates.io, I should probably warn about that. Or yank it.

This is good to know. Yes, it was a hack around using Ipv4Addr and Ipv6Addr to call .is_global(). Yes, the transmute is not at all future safe, I get the point. Since I published this to crates.io, I should probably warn about that. Or yank it.

faern commented

2024-02-14 11:21:45 +13:00

(Migrated from github.com)

IMHO a good strategy would be:

Remove the recommendation to transmute between this and std types.
Wait for the stabilization to actually happen (March 21)
Update the readme of this crate to recommend core::net instead, and say that this crate is deprecated. (Would be nice to say it with metadata and not only with words. for example with:
```
[badges] maintenance = { status = "deprecated" }
```
Not sure if this can be re-published to the existing version 0.1.0 or if a version bump is needed 🤔
For each known consumer of the crate, create an issue in their repositories nudging them towards using core::net instead.

I personally see no reason for yanking. The crate itself contains no known issues (only "issue" is in the readme :P). It's just that after March 21 there is no real use case except if you have a conservative MSRV for a project.

IMHO a good strategy would be: 1. Remove the recommendation to transmute between this and std types. 2. Wait for the stabilization to actually happen (March 21) 3. Update the readme of this crate to recommend `core::net` instead, and say that this crate is deprecated. (Would be nice to say it with metadata and not only with words. for example with: ```toml [badges] maintenance = { status = "deprecated" } ``` Not sure if this can be re-published to the existing version `0.1.0` or if a version bump is needed :thinking: 4. For each known consumer of the crate, create an issue in their repositories nudging them towards using `core::net` instead. I personally see no reason for yanking. The crate itself contains no known issues (only "issue" is in the readme :P). It's just that after March 21 there is no real use case except if you have a conservative MSRV for a project.

faern commented

2024-03-25 00:38:25 +13:00

(Migrated from github.com)

Rust 1.77 is out and core::net is stable. However, I see the way this is used in the only dependents on crates.io is to use is_global() on stable. This is of course still not possible, since that's a different unstable feature. So what this crate does is not really to enable IP types usage on no_std, which was my initial assumption was the reason for its existence, but rather allow the usage of the helper functions such as is_global.

This can easily be fixed with the existing code! No need to transmute, and also works safely across any version of Rust. I proposed the change in a PR: https://github.com/mikedilger/nostr-types/pull/14

I will close this issue since you have update the readme to not recommend transmuting 🙏

Rust 1.77 is out and `core::net` is stable. However, I see the way this is used in the only dependents on crates.io is to use `is_global()` on stable. This is of course still not possible, since that's a different unstable feature. So what this crate does is not really to enable IP types usage on `no_std`, which was my initial assumption was the reason for its existence, but rather allow the usage of the helper functions such as `is_global`. This can easily be fixed with the existing code! No need to transmute, and also works safely across any version of Rust. I proposed the change in a PR: https://github.com/mikedilger/nostr-types/pull/14 I will close this issue since you have update the readme to not recommend transmuting :pray: