Re: [PATCH] util/oslib-posix : qemu_init_exec_dir implementation for MacOS

["Philippe Mathieu-Daudé" <philmd@redhat.com>]

On 6/3/20 4:09 PM, Justin Hibbits wrote:
> On Wed, 3 Jun 2020 08:08:42 +0200
> Philippe Mathieu-Daudé <philmd@redhat.com> wrote:
> 
>> Cc'ing more developers.
>>
>> On 5/26/20 10:40 PM, David CARLIER wrote:
>>> From b24a6702beb2a4e2a9c1c03b69c6d1dd07d4cf08 Mon Sep 17 00:00:00
>>> 2001 From: David Carlier <devnexen@gmail.com>
>>> Date: Tue, 26 May 2020 21:35:27 +0100
>>> Subject: [PATCH] util/oslib: current process full path resolution
>>> on MacOS
>>>
>>> Using existing libproc to fill the path.
>>>
>>> Signed-off-by: David Carlier <devnexen@gmail.com>
>>> ---
>>>  util/oslib-posix.c | 13 +++++++++++++
>>>  1 file changed, 13 insertions(+)
>>>
>>> diff --git a/util/oslib-posix.c b/util/oslib-posix.c
>>> index 062236a1ab..96f0405ee6 100644
>>> --- a/util/oslib-posix.c
>>> +++ b/util/oslib-posix.c
>>> @@ -55,6 +55,10 @@
>>>  #include <sys/sysctl.h>
>>>  #endif
>>>
>>> +#ifdef __APPLE__
>>> +#include <libproc.h>
>>> +#endif
>>> +
>>>  #include "qemu/mmap-alloc.h"
>>>
>>>  #ifdef CONFIG_DEBUG_STACK_USAGE
>>> @@ -366,6 +370,15 @@ void qemu_init_exec_dir(const char *argv0)
>>>              p = buf;
>>>          }
>>>      }
>>> +#elif defined(__APPLE__)
>>> +    {
>>> +        uint32_t len;
>>> +        len = proc_pidpath(getpid(), buf, sizeof(buf) - 1);
>>> +        if (len > 0) {
>>> +            buf[len] = 0;
>>> +            p = buf;
>>> +        }
>>> +    }
>>>  #endif
>>>      /* If we don't have any way of figuring out the actual
>>> executable location then try argv[0].  */
>>>   
>>
> 
> Apologies, I don't have context for this.  Why was I CC'd on this?

I did after finding this patch of yours:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg639033.html

> 
> Does proc_pidpath() not NUL-terminate its written string?  And, given
> from my quick google search, it looks like this function is private and
> subject to change, so can you guarantee that the returned length is the
> *written* length, not the full string length?  If not, you could be
> overwriting other arbitrary data.
> 
> - Justin
>