On 6/3/20 4:09 PM, Justin Hibbits wrote:
> On Wed, 3 Jun 2020 08:08:42 +0200
> Philippe Mathieu-Daudé <phi...@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 <devne...@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 <devne...@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
>
