Re: [PATCH] open: Normalize tricky .file names

[Eric Blake]

On 2/26/20 2:39 PM, Eric Blake wrote:
> Otherwise, we can run into:
> $ touch "*#1*"
> $ ./run poke
> (poke) .mem #0
> The current IOS is now `*#0*'.
> (poke) .file "*#1*"
> The current IOS is now `*#1*'.
> (poke) .mem #1
> Buffer *#1* already opened.  Use `.ios #N' to switch.
>
> * src/ios-dev.h (struct ios_dev_if): Replace handler_p with
> handler_noramlize callback.
> * src/ios.c (ios_open): Store normalized name per ios.
> * src/ios-dev-file.c (ios_dev_file_handler_p): Rename...
> (ios_dev_file_handler_normalize): ...and prepend ./ to risky
> relative file names.
> * src/ios-dev-mem.c (ios_dev_mem_handler_p): Rename...
> (ios_dev_mem_handler_normalize): ...to this.
> (ios_dev_mem_open, ios_dev_mem_close): Drop unused handler member.
> * testsuite/poke.cmd/file-relative.pk: New test.
> ---
>   ChangeLog                           | 14 ++++++++++++++
>   src/ios-dev-file.c                  | 23 ++++++++++++++++++-----
>   src/ios-dev-mem.c                   | 12 +++++-------
>   src/ios-dev.h                       |  6 +++---
>   src/ios.c                           |  4 ++--
>   testsuite/poke.cmd/file-relative.pk |  7 +++++++
>   6 files changed, 49 insertions(+), 17 deletions(-)
>   create mode 100644 testsuite/poke.cmd/file-relative.pk

Argh - I have no idea why my emails are sending in a different order 
than my local 'git log', after my recent addition of etc/git.orderfile. 
I'm pursuing that separately on the git mailing list (I think it's a bug 
in git send-email that it fails to honor diff.orderfile).


> +++ b/src/ios-dev-mem.c
> @@ -28,7 +28,6 @@
>
>   struct ios_dev_mem
>   {
> -  char *handler;
>     char *pointer;
>     size_t size;
>     size_t cur;
> @@ -38,10 +37,11 @@ struct ios_dev_mem
>   #define MEM_STEP (512 * 8)
>
>   static int
> -ios_dev_mem_handler_p (const char *handler)
> +ios_dev_mem_handler_normalize (const char *handler)

I missed s/int/char */ in the prototype; but since I'm not using 
-Werror, I didn't notice the compilation warning.  Obviously that would 
be fixed before pushing, if we like the idea.

> +++ b/src/ios-dev.h
> @@ -47,7 +47,7 @@ typedef uint64_t ios_dev_off;
>   struct ios_dev_if
>   {
>     /* Determine whether the provided HANDLER is recognized as a valid
> -     device spec by this backend.  Return 1 if the handler is
> -     recognized, 0 otherwise.  */
> +     device spec by this backend, and if so, return its normalized
> +     form (caller will free).  If not, return NULL.  */
>
> -  int (*handler_p) (const char *handler);
> +  char *(*handler_normalize) (const char *handler);

--
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org