Le 28/10/2019 à 16:46, Nathan Lynch a écrit :
Hi Christophe,
Christophe Leroy writes:
Hi Nathan,
While trying to switch powerpc VDSO to C version of gettimeofday(), I'm
getting the following kind of error with vdsotest:
passing NULL to clock_getres (VDSO): terminated by unexpected signal
Hi Christophe,
Christophe Leroy writes:
> Hi Nathan,
>
> While trying to switch powerpc VDSO to C version of gettimeofday(), I'm
> getting the following kind of error with vdsotest:
>
> passing NULL to clock_getres (VDSO): terminated by unexpected signal 11
>
> Looking at commit a9446a906f52
From: Thomas Gleixner
> Sent: 20 October 2019 20:53
> On Sun, 20 Oct 2019, Andreas Schwab wrote:
> > On Okt 20 2019, Thomas Gleixner wrote:
> >
> > > POSIX does not mention anything about the validity of the pointer handed
> > > to
> > > clock_getres().
> >
> > Sure it does: "If the argument res
On Okt 20 2019, Thomas Gleixner wrote:
> But for the sake of making a non-sensical specification happy we can add a
> NULL pointer check for this. The interesting question is what should be
> returned in this case.
0 if the clock id is valid, EINVAL otherwise.
Andreas.
--
Andreas Schwab,
On Sun, 20 Oct 2019, Andreas Schwab wrote:
> On Okt 20 2019, Thomas Gleixner wrote:
>
> > POSIX does not mention anything about the validity of the pointer handed to
> > clock_getres().
>
> Sure it does: "If the argument res is not NULL, the resolution of the
> specified clock shall be stored in
On Okt 20 2019, Thomas Gleixner wrote:
> POSIX does not mention anything about the validity of the pointer handed to
> clock_getres().
Sure it does: "If the argument res is not NULL, the resolution of the
specified clock shall be stored in the location pointed to by res. If
res is NULL, the
On Sun, 20 Oct 2019, Andreas Schwab wrote:
> On Okt 20 2019, Thomas Gleixner wrote:
>
> > clock_getres(NULL) is hardly valid.
>
> Of course not, it lacks a parameter.
You know exactly what I mean.
> > So special casing
> >
> > clock_getres(clock, NULL);
> >
> > just to make a test case
On Okt 20 2019, Thomas Gleixner wrote:
> clock_getres(NULL) is hardly valid.
Of course not, it lacks a parameter.
> So special casing
>
> clock_getres(clock, NULL);
>
> just to make a test case happy is a pointless exercise which does not make
> any sense at all.
POSIX requires it to
On Sun, 20 Oct 2019, Christophe Leroy wrote:
> Adding Thomas to the discussion as the commit is from him.
>
> Le 20/10/2019 à 11:53, Andreas Schwab a écrit :
> > On Okt 20 2019, Christophe Leroy wrote:
> >
> > > Le 19/10/2019 à 21:18, Andreas Schwab a écrit :
> > > > On Okt 19 2019, Christophe
Adding Thomas to the discussion as the commit is from him.
Le 20/10/2019 à 11:53, Andreas Schwab a écrit :
On Okt 20 2019, Christophe Leroy wrote:
Le 19/10/2019 à 21:18, Andreas Schwab a écrit :
On Okt 19 2019, Christophe Leroy wrote:
Hi Nathan,
While trying to switch powerpc VDSO to C
On Okt 20 2019, Christophe Leroy wrote:
> Le 19/10/2019 à 21:18, Andreas Schwab a écrit :
>> On Okt 19 2019, Christophe Leroy wrote:
>>
>>> Hi Nathan,
>>>
>>> While trying to switch powerpc VDSO to C version of gettimeofday(), I'm
>>> getting the following kind of error with vdsotest:
>>>
>>>
Le 19/10/2019 à 21:18, Andreas Schwab a écrit :
On Okt 19 2019, Christophe Leroy wrote:
Hi Nathan,
While trying to switch powerpc VDSO to C version of gettimeofday(), I'm
getting the following kind of error with vdsotest:
passing NULL to clock_getres (VDSO): terminated by unexpected
On Okt 19 2019, Christophe Leroy wrote:
> Hi Nathan,
>
> While trying to switch powerpc VDSO to C version of gettimeofday(), I'm
> getting the following kind of error with vdsotest:
>
> passing NULL to clock_getres (VDSO): terminated by unexpected signal 11
>
> Looking at commit a9446a906f52
13 matches
Mail list logo
