Before xous-ipc's fixed-length string guaranteed this thing
fit into a single page. Now, we can send potentially unbounded
amounts of text between servers.
I don't think it makes sense to send more than a few k of text to
render on the screen at once, given our screen sizes, so I've added
a patch that truncates the text to the previous length that things
would truncate to.
The behavior is the same as before, except that you will
over-allocate memory on the heap in the sending process
as you shove more string data into a TextView than can be rendered.
Previously, the TextView would just truncate the data and discard
the data.
The truncation happens at the point where you try to hand the
record off to another process, so, one could in theory try
to make this recoverable by adding a layer that splits the
textview into more manageable chunks or pages the data, but that
is an exercise for another day.
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.
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
