Hi,
On Mon, 18 Nov 2013 21:59:52 -0800, Martynas Venckus <[email protected]> wrote:
> > 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.
I admit I only tested on NetBSD and assumed it would be pretty much the same on
OpenBSD, as the failures are the same there.
On NetBSD, those values are under
#if defined(_XOPEN_SOURCE) || defined(_NETBSD_SOURCE)
Libav configure defines _XOPEN_SOURCE=600, so they get exported.
>
> > 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?
>
Only happens on 32bit and with -std=c99 (more precisely
-fexcess-precision=standard, which is enabled by -std=c99).
You also have to #include <limits.h> after <float.h>.
> > 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.
>
We probably still want to make it work on all the current versions of
{Net,Open}BSD. I was going to poke the upstreams eventually, but I appreciate
that you contacted us first.
> > 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?
I did not look at the patches you have directly, but
- the C99 standard specifies that unqualified floating point literals must be
treated as double (6.4.4.2.4)
- the version of gcc on NetBSD clearly does the comparison in extended
precision, so gcc must violate the standard. I assume OpenBSD behaves the
same, since it fails in the same way.
- the vanilla gcc behaves correctly
from this I conclude that you probably have some patches which break this.
--
Anton Khirnov
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
