the implementation relied on a quirk of xous-ipc where the message
ID is 0 for string send/receives. This cleans it up so that the API
is transparent and consistent with other API calls in the system.
the into/from inner methods are useful for using the Buffer
abstraction as a way to invoke rkyv on a structure to serialize
it and then manipulate the serialized data directly
And I did it! and it's now fixed.
I was using xous-ipc String to make a fixed-length string in a
structure that's not strictly an IPC structure.
The solution to this is to just implement a fixed length string
directly.
I think this is safe to do because no strings can be directly
serialized into the PDDB's structures. The place to check for
this is inside the backend/ directory. For example, `DictName`
is where the name field is serialized into a structure that
goes onto the disk. It's explicitly length-checked.
What this means is that we could have calls into the pddb crate
with invalid length strings, however, if you check the lib
implementation, all of the APIs also pre-flight the length of
arguments to ensure they fit into the destination string.
So mostly what we're losing is the constraints on the intermediate
IPC representation, but the length is still checked on either side.
a bunch of lines are shorter or different length now which
triggers a mandatory reformat. this patch cleans that up,
so that going forward the manual rework patches are clearer and
not tied up with formatting patches.
note for more review by bunnie down the road to make sure
that I have not changed any behaviors accidentally in fixing
the loss of Copy on a core structure
The original loop takes advantage of the copy-trait that is
no longer available. I think the intent of the loop was to
mutate a field within the copy through each iteration so you
can update the prompt to handle field validations that failed
without re-allocating the ManagedPromtWithTextResponse structure.
This has been rewritten to alloc that each iteration to avoid
the borrow error, and instead the `prompt` itself is a string
that's initialized with the initial prompt message and is updated
on each iteration if the form validation fails.
@gsora git seems to say you wrote this code, maybe I could use
your help to review this patch.
There isn't a simple regex to deal with the loss of Copy when
deprecating xous_ipc, so this has to be a manual pass.
Losing the copy trait means (maybe) some loss of efficiency
in the API because we have to clone some structures instead
of copying them, although, I think actually what might have
been happening under the hood anyways is the copy was implemented
as a clone-under-the-hood for the xous-ipc.
Either way, this happens in the high level management structures
for modals, so it's not the end of the world to incur a clone
on the description of the structures -- we'd have to pay
more attention if this happened e.g. at the pixel shuffling
level, but a few UI strings at human-interaction rates
isn't going to kill us.
xous_ipc::<String> had a clear-volatile() API for zeroizing
sensitive strings.
This is now missing in String, so it has been manually implemented
here by casting the String to a slice-u8 and then iterating
through it using raw pointers and volatile writes with a compiler
barrier to hopefully avoid all of the landmines I know of for
zeroizing a string...
commit is called out separately because this one is one of the
more "dangerous" security-related changes in the API migration.
Rust can't tell how to cast some u32_le into u32/usize automatically
due to confusion with the num_derive trait, so we have to explicitly
specify a chain of typecasts to clean up the conflict with the
new rkyv
Turns out, this is the wrong approach. It's still useful code
because it's a direct method for passing strings that doesn't
rely on rkyv (so it could potentially be more efficient for
very efficiency-oriented applications).
But I think in the end, after writing this and seeing the errors
that come from it, I think we should just abandon String<N> altogether
because it doesn't get us anything.
