Re: [LTP] EINVAL vs. SIGSEGV

[Paul L. <pl...@li...>]

On Thu, 2003-04-10 at 18:33, Dan Kegel wrote:
> clone04 checks to see if clone() returns EINVAL
> when handed a null pointer.  It passes on x86 and ppc,
> but for us it fails on sh4, where clone(... NULL ...)
> causes a SIGILL (for a null function) or SIGSEGV (for null stack).
I can't point to it at the moment, but I seem to remember something in
posix about EINVAL and SIGSEGV always being legal in the same
situation.  I think we've run into this a few times before where one
arch will return EINVAL while another will SIGSEGV and both are valid.=20
Known tests where this happens have been modified to accept either.  I'm
not sure about SIGILL though.

> I don't see any guidance on this question in LSB other than
> what's in Posix, which suggests that it's ok for functions to signal
> instead of returning error codes in the case of bad pointers.
> So perhaps this test case should also allow for
> a signal to be sent instead of EINVAL being returned?
> If the group is ok with that, I'd be happy to submit
> a patch to implement that.
Sounds good, there should be plenty of examples already in LTP so this
isn't a new thing.  The SIGSEGV/EINVAL thing should be no problem, but
we might want to check to be certain that the SIGILL is valid first.=20
That sounds a little odd.

-Paul Larson