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
>
> Lookin
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 Okt 19 2019, Christophe Leroy wrote:
> > > >
> > > > > Hi Nathan,
> > > > >
> > > > > While trying to switch powerpc VDSO to C version of gettimeofday(),
> > > > > I'm
> > > > > getting the
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 ("lib/vdso/32: Remove inconsistent NULL
pointer checks"), it seems that signal 11 is expected when pa
; getting the following kind of error with vdsotest:
>>>
>>> passing NULL to clock_getres (VDSO): terminated by unexpected signal 11
>>>
>>> Looking at commit a9446a906f52 ("lib/vdso/32: Remove inconsistent NULL
>>> pointer checks"), it seems that
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
>
> Lookin
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 ("lib/vdso/32: Remove inconsistent NULL
pointer c
14 matches
Mail list logo
