qemu-trivial
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David CARLIER
Subject: Re: [PATCH] util/oslib-posix : qemu_init_exec_dir implementation for MacOS
Date: Wed, 3 Jun 2020 15:22:26 +0100

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 <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..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 <chmeeedalf@gmail.com> 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?
>
> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]