Dave Martin <Dave.Martin@xxxxxxx> writes:
> On Mon, Jan 22, 2018 at 03:13:08PM -0600, Eric W. Biederman wrote:
>>
>> > diff --git a/include/uapi/asm-generic/siginfo.h b/include/uapi/asm-generic/siginfo.h
>> > index e447283..77edb00 100644
>> > --- a/include/uapi/asm-generic/siginfo.h
>> > +++ b/include/uapi/asm-generic/siginfo.h
>> > @@ -193,7 +193,8 @@ typedef struct siginfo {
>> > #define FPE_FLTRES 6 /* floating point inexact result */
>> > #define FPE_FLTINV 7 /* floating point invalid operation */
>> > #define FPE_FLTSUB 8 /* subscript out of range */
>> > -#define NSIGFPE 8
>> > +#define FPE_UNKNOWN 9 /* undiagnosed floating-point exception */
>> > +#define NSIGFPE 9
>>
>> Minor nit here.
>>
>> At least before this is final I would really appreciate if you could
>> rebase this on top of my unificiation of siginfo.h that I posted on
>> linux-arch and is in my siginfo-next branch.
>>
>> As that already pushes NSIGFPE up to 13.
>>
>> Which would make this patch change NSIGFPE to 14 and allocate the number
>> 14 for FPE_UNKNOWN
>
> My bad -- I hadn't looked in detail at the whole series.
>
> However, the purpose of this as an RFC was to get feedback on whether
> adding FPE_UNKNOWN is considered acceptable at all from an API
> perspective -- the precise number doesn't matter for that discussion.
>
> Do you have any view on this?
That seems as good a solution as any too me. It is reality and it
happens in the code and there are several places of the same form I
would use it, just to get rid of the FPE_FIXME.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-api" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
