Good point even tough the libproc api is here in this form since quite a time.
>From d23bf60961ee036f8298794f879d1b8b9bd717dc 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..9dd1e1a18b 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__)
+ {
+ int len;
+ len = proc_pidpath(getpid(), buf, sizeof(buf) - 1);
+ if (len <= 0) {
+ return;
+ }
+ p = buf;
+ }
#endif
/* If we don't have any way of figuring out the actual executable
location then try argv[0]. */
--
2.26.2
On Wed, 3 Jun 2020 at 15:09, Justin Hibbits <chmeeed...@gmail.com> 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?
>
> 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
