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