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 s
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
>
> L
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 i
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, sch..
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 cloc
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 h
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 work.
> > > On Okt 19 2019, Christophe Leroy wrote:
> > > >
> > > > > Hi Nathan,
> > > > >
> > > > > While trying to switch powerpc VDSO to C version of gettimeofday(),
> > > > > I'm
> > > > > gettin
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 wh
t;> 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 tha
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 unexp
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
>
> L
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
poin
14 matches
Mail list logo
