Scott Cheloha <[email protected]> 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 see is > > > EFAULT. But I'm unsure if that's possible. Can we get an EFAULT if > > > both arguments point to stack memory? > > > > I don't think it is possible for alarm(3) to fail in this case. > > The only way I see it failing is if the stack gets corrupted. I > > think we can just initialize oitv to { 0 } and ignore the setitimer() > > return value. > > Can we abort if setitimer(2) fails? Or is that too extreme? I know > we're not supposed to leave land mines in libc, but in this case we're > be saying "if this fails then the program state is very screwed up". > > I know we do that in a couple spots in libc. > > ... at minimum we can remove the pointer itp from the stack. It > doesn't serve any purpose.
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 there is no corefile, and noone is the wiser and it never gets fixed. Isn't that the truth?
