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?
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
