chrysn

Results 707 comments of chrysn

Having this stable would also enable its use with the riot-wrappers crate, where for example process names are exposed (they're by all probability ASCII even, but an unsafe assume-it-is opens...

Relevant build reports, now that I've made the github actions happy: * When only the new test is added, https://github.com/chrysn-pull-requests/cstr/runs/7600662935?check_suite_focus=true#step:4:18 shows how running in a no_std environment fails. * After...

I completely missed that the `cstr!` macro is *not* part of std/core. Thus, if you should decide decide to mothball this crates CStr type, there are two ways forward: *...

Fine with me, thanks for clarifying. > ` c"xxx"` I think it's a bit too niche to warrant a dedicated literal type, but I hope the standard library will provide...

Agreeing with @Amanieu. "length" has two distinct meanings here (length with and length without the nul), so it's better to explicitly indicate *which* length to get either by using `.to_bytes()`...

I understand this issue to be about the numerics of largly offset values, not about actually differentiating between 1000m and 1km. To keep issues separate and not pull in a...

The particular crate itself is more of an application practically, but the ecosystem (WASM) for which it is built practically requires it to be declared as a library. When a...

Hm, doing the second is a lot harder than anticipated -- during build time, the working directory is the crate-being-built (be it in its specified path, or if downloaded in...

… and has been [stabilized](https://github.com/rust-lang/rust/pull/98315) aiming for 1.64.

It does fix the build issues. I'm stuck on https://github.com/rust-lang/compiler-builtins/issues/400 so can't do runtime evaluation of them right now. (The established workaround appears to be to use a 2021-01 nightly,...