This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: fegetexceptflag() question for ppc


Ulrich Drepper <drepper@redhat.com> writes:

> Geoff Keating wrote:
> 
> > It has to return at least the exceptions in 'excepts', but it doesn't
> > hurt if it returns more.
> 
> Where do you get this from?  ISO C says that the status flags indicated
> by excepts is returned.  Nothing more or less.  So the function has to
> perform the masking.

ISO C says:

> The fegetexceptflag function stores an implementation-defined
> representation of the states of the floating-point status flags
> indicated by the argument excepts in the object pointed to by the
> argument flagp.

On powerpc, the representation is defined to be in the format of the
FP environment register with bits other than those specified by
'excepts' having undefined values.

ISO C also says:

> The fesetexceptflag function sets the floating-point status flags
> indicated by the argument excepts to the states stored in the object
> pointed to by flagp. The value of *flagp shall have been set by a
> previous call to fegetexceptflag whose second argument represented
> at least those floating-point exceptions represented by the argument
> excepts. This function does not raise floating-point exceptions, but
> only sets the state of the flags.

and these are the only routines that interpret a fexcept_t.  So
there's no way a conforming program can tell that fegetexceptflag is
returning more information than requested.

You might think that you could use memcmp() to compare two fexcept_t
structures, and tell if the flags in 'excepts' have changed, and this
would break with this definition.  Unfortunately, this doesn't work
anyway, because the implementation might have done:

typedef struct {
  bool flag_1;
  int rest_of_flags;
} fexcept_t;

which has a 'hole' in it, see footnote 262 on page 327 (attached to
the description of memcmp).

-- 
- Geoffrey Keating <geoffk@geoffk.org>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]