> It defines {FLT,DBL}_{MAX,MIN} macros, even though float.h is supposed
> to do that.
Nope. In OpenBSD, only if you #define _XOPEN_SOURCE < 600, as it's
required by XPG3 - XPG5v2.
> Those values are not exactly representable double/float as
> the specification mandates, which breaks code (e.g. in vf_fps) like
>
> double f = DBL_MAX;
> [...]
> if (f == DBL_MAX) { // f has not been changed yet
> [....]
> }
So this is the exact same snippet running on OpenBSD/i386 (tested with -O0,
-O1, -O2):
martynas:64$ cat a.c
#include <float.h>
int
main(void)
{
double f = DBL_MAX;
if (f == DBL_MAX) {
return (1);
}
return (0);
}
martynas:65$ gcc a.c
martynas:66$
./a.out
martynas:67$ echo $?
1
Can you help me reproduce this bug?
> compat/bsd/limits.h | 41 +++++++++++++++++++++++++++++++++++++++++
> configure | 2 ++
> 2 files changed, 43 insertions(+)
> create mode 100644 compat/bsd/limits.h
Whoa, instead of patching things around, can we do this right and fix it
upstream? It's not like the upstream is uncooperative.
> Fixed the description of the cause -- a patched gcc that violates the
standard
> also collaborates on the breakage.
Can you point me to the gcc patch that violates the standard?
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
