On 07.05.2020 05:56, Martin Husemann wrote:
> On Thu, May 07, 2020 at 05:43:02AM +0200, Kamil Rytarowski wrote:
>> I propose the following patch:
>>
>> http://netbsd.org/~kamil/patch-00250-libatomic.txt
>
> +__inline static int
> +__futex(volatile uint32_t *uaddr, int op, int val, const struct tim
On Thu, May 07, 2020 at 05:43:02AM +0200, Kamil Rytarowski wrote:
> I propose the following patch:
>
> http://netbsd.org/~kamil/patch-00250-libatomic.txt
+__inline static int
+__futex(volatile uint32_t *uaddr, int op, int val, const struct timespec
*timeout,
+volatile uint32_t *uaddr2, i
Lack of libatomic is increasingly hard to deal with. This library
implements function calls for atomic operations.
Personally I stopped testing sanitizers year ago as they required
libatomic. We want libatomic for LLDB in base. Rewritting everything to
stop using libatomic is no viable as this is
On Wed, May 06, 2020 at 10:03:54PM +0700, Robert Elz wrote:
> | We have a summer of code project that can cover this part.
>
> Thanks for the info, which project is that, and who is mentoring it,
> if you know? (I am woefully ignorant of everything related to GSoC).
See https://summerofcode.w
Date:Wed, 6 May 2020 15:16:06 +0200
From:Martin Husemann
Message-ID: <20200506131606.gb2...@mail.duskware.de>
| Ok, but you can set PATH to : or something.
Not that, at least not to make posix_spawnp() work - that uses
strtok() to parse PATH, and that (apparently)
On Wed, May 06, 2020 at 02:51:28PM +0200, Joerg Sonnenberger wrote:
> The environment is under the control of the user, the code isn't.
Ok, but you can set PATH to : or something.
Martin
On Wed, May 06, 2020 at 02:31:32PM +0200, Martin Husemann wrote:
> On Wed, May 06, 2020 at 02:29:07PM +0200, Joerg Sonnenberger wrote:
> > I'm not sure. There is normally no way to force an empty environment
> > variable, so if you want to not use PATH, the behavior of the current
> > code is more
On Wed, May 06, 2020 at 02:29:07PM +0200, Joerg Sonnenberger wrote:
> On Wed, May 06, 2020 at 10:43:05AM +0200, Martin Husemann wrote:
> > On Wed, May 06, 2020 at 02:33:41PM +0700, Robert Elz wrote:
> > > Either of those is fine with POSIX - but we should really have one
> > > consistent
> > > pol
On Wed, May 06, 2020 at 02:33:41PM +0700, Robert Elz wrote:
> Aside: I started looking because POSIX is adding a "chdir" file action
> to posix_spawn and posix_spawnp - and the path search (for relative paths)
> done by posix_spawnp is to be applied after the effects of the chdir, which
> would mea
On Wed, May 06, 2020 at 02:29:07PM +0200, Joerg Sonnenberger wrote:
> I'm not sure. There is normally no way to force an empty environment
> variable, so if you want to not use PATH, the behavior of the current
> code is more useful.
But you can then just use posix_spawn() instead.
Martin
On Wed, May 06, 2020 at 10:43:05AM +0200, Martin Husemann wrote:
> On Wed, May 06, 2020 at 02:33:41PM +0700, Robert Elz wrote:
> > Either of those is fine with POSIX - but we should really have one
> > consistent
> > policy. Changing either the manual or the code to match the other is also
> > e
On Wed, May 06, 2020 at 02:33:41PM +0700, Robert Elz wrote:
> Either of those is fine with POSIX - but we should really have one consistent
> policy. Changing either the manual or the code to match the other is also
> easy. What is not so easy is to decide which of the two (or perhaps
> somethi
Our man page for posix_spawnp() says...
The file parameter to posix_spawnp() is used to construct a pathname that
identifies the new process image file. If the file parameter contains a
slash character, the file parameter is used as the pathname for the new
process image file.
13 matches
Mail list logo
