On Sat, 19 Jun 2021 17:15:43 +0200, Alexander Bluhm wrote:
> In regress is some code
> if ((int)alarm(10) == -1)
> or
> if (alarm(30) == (unsigned int)-1)
>
> The man page alarm(3) says "If an error occurs, the value -1 is
> returned". Such things could be written.
>
> Should we avoid to
> > > On Fri, 18 Jun 2021 15:17:47 -0600, "Theo de Raadt" wrote:
> > > > OK. How any pieces of code were found which do that?
In regress is some code
if ((int)alarm(10) == -1)
or
if (alarm(30) == (unsigned int)-1)
The man page alarm(3) says "If an error occurs, the value -1 is
On Fri, 18 Jun 2021 15:22:05 -0600, "Theo de Raadt" wrote:
> Todd C. Miller wrote:
>
> > On Fri, 18 Jun 2021 15:17:47 -0600, "Theo de Raadt" wrote:
> >
> > > OK. How any pieces of code were found which do that?
> > >
> > > I mean, code search for ' = alarm('
> >
> > In our tree? Just ksh.
>
Todd C. Miller wrote:
> On Fri, 18 Jun 2021 15:17:47 -0600, "Theo de Raadt" wrote:
>
> > OK. How any pieces of code were found which do that?
> >
> > I mean, code search for ' = alarm('
>
> In our tree? Just ksh.
>
> static void
> alarm_catcher(int sig)
> {
> int errno_ = errno;
>
On Fri, 18 Jun 2021 15:17:47 -0600, "Theo de Raadt" wrote:
> OK. How any pieces of code were found which do that?
>
> I mean, code search for ' = alarm('
In our tree? Just ksh.
static void
alarm_catcher(int sig)
{
int errno_ = errno;
if (ksh_tmout_state == TMOUT_READING) {
Todd C. Miller wrote:
> On Fri, 18 Jun 2021 15:05:52 -0600, "Theo de Raadt" wrote:
>
> > Without considering the cases where an incorrect value is passed in...
> >
> > How many pieces of code have you found that inspect the return value?
>
> Very few. My concern is for those that use the
On Fri, 18 Jun 2021 15:05:52 -0600, "Theo de Raadt" wrote:
> Without considering the cases where an incorrect value is passed in...
>
> How many pieces of code have you found that inspect the return value?
Very few. My concern is for those that use the return value when
determining how much
Todd C. Miller wrote:
> On Fri, 18 Jun 2021 16:02:20 -0500, Scott Cheloha wrote:
>
> > If we're going to just return an arbitrary value shouldn't we keep
> > returning UINT_MAX as we always have? This would preserve compat with
> > the other BSD libc implementations, too.
>
> I think that a
On Fri, 18 Jun 2021 16:02:20 -0500, Scott Cheloha wrote:
> If we're going to just return an arbitrary value shouldn't we keep
> returning UINT_MAX as we always have? This would preserve compat with
> the other BSD libc implementations, too.
I think that a return value of 0 is less likely to
On Fri, Jun 18, 2021 at 12:27:13PM -0600, Theo de Raadt wrote:
> Todd C. Miller wrote:
>
> > On Fri, 18 Jun 2021 12:13:54 -0600, "Theo de Raadt" wrote:
> >
> > > I don't understand what you are solving.
> > >
> > > The way I look at it... you want to convert one kind of bug into a
> > >
Todd C. Miller wrote:
> On Fri, 18 Jun 2021 12:13:54 -0600, "Theo de Raadt" wrote:
>
> > I don't understand what you are solving.
> >
> > The way I look at it... you want to convert one kind of bug into a
> > different kind of bug?
> >
> > In the end, the program quits, noone looks at the
On Fri, 18 Jun 2021 12:13:54 -0600, "Theo de Raadt" wrote:
> I don't understand what you are solving.
>
> The way I look at it... you want to convert one kind of bug into a
> different kind of bug?
>
> In the end, the program quits, noone looks at the corefile, or is it
> in a privsep program and
Scott Cheloha wrote:
> On Fri, Jun 18, 2021 at 09:15:31AM -0600, Todd C. Miller wrote:
> > On Tue, 15 Jun 2021 20:22:53 -0500, Scott Cheloha wrote:
> >
> > > After that is committed, I'm unclear whether alarm(3) can fail anymore
> > > on OpenBSD. The only remaining plausible failure case I can
On Fri, Jun 18, 2021 at 09:15:31AM -0600, Todd C. Miller wrote:
> On Tue, 15 Jun 2021 20:22:53 -0500, Scott Cheloha wrote:
>
> > After that is committed, I'm unclear whether alarm(3) can fail anymore
> > on OpenBSD. The only remaining plausible failure case I can see is
> > EFAULT. But I'm
On Tue, 15 Jun 2021 20:22:53 -0500, Scott Cheloha wrote:
> After that is committed, I'm unclear whether alarm(3) can fail anymore
> on OpenBSD. The only remaining plausible failure case I can see is
> EFAULT. But I'm unsure if that's possible. Can we get an EFAULT if
> both arguments point to
I have a patch on tech@ to raise the setitimer(2) input limit to
UINT_MAX seconds:
https://marc.info/?l=openbsd-tech=162343190813127=2
After that is committed, I'm unclear whether alarm(3) can fail anymore
on OpenBSD. The only remaining plausible failure case I can see is
EFAULT. But I'm
16 matches
Mail list logo
