provide core-only mode (i.e., no-std and no-alloc)
#168
Comments
|
When I initially started building Jiff, it was my original intention to provide a One reason why I abandoned that goal was because it was much harder to devise a useful and chain-able Another thing that seems to be mentioned above is time zone support. Currently, Jiff requires Another thing is that And types like I'd say core-only support looks pretty challenging at this point, but not impossible. |
As part of working toward #168, this commit puts POSIX time zone abbreviations inline instead of on the heap. We can generally rely on time zone abbreviations to be short, so this is "fine." This is obviously more annoying than just using `Box<str>`, which explains why I didn't do it this way initially. But it seems like a no-std no-alloc mode is a good idea, so let's put in the effort to do this right. We do limit abbreviation strings to 30 bytes (previously 255), but this seems bigger than the limits used by GNU software, so it should be fine. Still, 30 bytes is a little chunky. But a POSIX time zone is only usable from Jiff's public API via a `TimeZone`, and in that context, it's guarded behind an `Arc`. So we should be fine. (Although, of course, this `Arc` will disappear in core-only mode... Oh well.) Note that we could simply declare that POSIX time zones aren't supported in core-only mode, but they _almost_ don't rely on allocation today. It just requires a little more work. Our short abbreviation strings are now represent by a simple "array string" of fixed capacity. We define a generic array string since it seems plausible that we'll use it again.
As part of working toward #168, this commit puts POSIX time zone abbreviations inline instead of on the heap. We can generally rely on time zone abbreviations to be short, so this is "fine." This is obviously more annoying than just using `Box<str>`, which explains why I didn't do it this way initially. But it seems like a no-std no-alloc mode is a good idea, so let's put in the effort to do this right. We do limit abbreviation strings to 30 bytes (previously 255), but this seems bigger than the limits used by GNU software, so it should be fine. Still, 30 bytes is a little chunky. But a POSIX time zone is only usable from Jiff's public API via a `TimeZone`, and in that context, it's guarded behind an `Arc`. So we should be fine. (Although, of course, this `Arc` will disappear in core-only mode... Oh well.) Note that we could simply declare that POSIX time zones aren't supported in core-only mode, but they _almost_ don't rely on allocation today. It just requires a little more work. Our short abbreviation strings are now represent by a simple "array string" of fixed capacity. We define a generic array string since it seems plausible that we'll use it again.
This removes yet another needless but harmless allocation in pursuit of progress on #168. In this case, returning a `&str` is part of the public API when a time zone is a fixed offset, so we do need to store the offset as a string somewhere. Thankfully, it's pretty small (smaller than a `Box<str>`) and there's a predictable maximum length on the string. So it's not a big deal to just generate the string on the stack and store it in the `TimeZone` for this case.
This removes yet another needless but harmless allocation in pursuit of progress on #168. In this case, returning a `&str` is part of the public API when a time zone is a fixed offset, so we do need to store the offset as a string somewhere. Thankfully, it's pretty small (smaller than a `Box<str>`) and there's a predictable maximum length on the string. So it's not a big deal to just generate the string on the stack and store it in the `TimeZone` for this case.
From a report on reddit:
Of course, thank you for taking the time to reply!
In an embedded context, there are lots of times where you need to work with Date/Time. For example, parsing messages that contain timestamps, scheduling events, or working directly with Time/Date providers like a GNSS (GPS) engine or NTP.
On one of the devices we create at work provides logging capabilities with time stamped entries, and we fetch time via an NTP request. We also allow the user to adjust this time to account for their timezone. This requires us to work with timestamps using (currently) Chrono, but it's not always the easiest to work with.
We also commonly work with GNSS engines which provide time in awkward formats like time since epoch, or directly as UTC, which is where a crate like yours would be great.
IOT and Low-power devices used for home automation need to work with timestamps to schedule events, by converting this into a hardware timer to trigger the event or wake-up from low power mode.
Commonly libraries that are
no-stdand noallocfeature gate any formatting or string output, because string is heap allocated, but with crates likeheaplessanddefmtused everywhere in embedded it would be helpful to be able to write into fixed size buffers instead.I understand not wanting to bump MSVR, it's always difficult to balance keeping up with the ecosystem whilst maintaining support for those on older versions. Unfortunately embedded is quickly gaining traction and features are being added in the latest version to support this, so we are usually chasing the newest rust version!
The text was updated successfully, but these errors were encountered: