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.
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.
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.
looks like about 9 crates will be affected by this. Point them
all to the latest version of the API, and specify the
"precursor" feature (which activates our patch)
