[FFmpeg-devel] [PATCH] Fix compilation on OpenBSD

[Måns Rullgård]

Andrew Savchenko wrote:
> Hi,
>
> On Tuesday 18 November 2008 00:25, M?ns Rullg?rd wrote:
> [...]
>> > But I'm not a system owner and I'm not allowed to install this
>> > kind of software outside of main ports tree.)
>>
>> How can anyone live under such conditions?
>
> Security implies some limitations.

I doubt that make 3.80 is any more or less secure than make 3.81, but
whatever.

> Obviously, this system is not a desktop, but mencoder power was
> required here. Anyway I'll install newer gmake in my local private
> path later.

It's your only option if you want to build FFmpeg...

>> > Index: libavcodec/nellymoserenc.c
>> > ==============================================================
>> > --- libavcodec/nellymoserenc.c	(revision 15864)
>> > +++ libavcodec/nellymoserenc.c	(working copy)
>> > @@ -45,6 +45,10 @@
>> >  #define POW_TABLE_SIZE (1<<11)
>> >  #define POW_TABLE_OFFSET 3
>> >
>> > +#if !defined(INFINITY) && defined(HUGE_VAL)
>> > +#define INFINITY HUGE_VAL
>> > +#endif
>>
>> 1. INFINITY is as standard as HUGE_VAL, so anywhere you find
>> one, you should have the other.
>
> I doubt it, HUGE_VAL is definitely in POSIX, but I can't find
> nothing about INFINITY. This is some cite from math.h in OpenBSD:

OpenBSD headers are not the authoritative POSIX reference.  Please
consult the actual spec next time.

> ===================================
> /*
>  * ANSI/POSIX
>  */
> extern char __infinity[];
> #define HUGE_VAL        (*(double *)(void *)__infinity)
>
> And from Linux box:
> ===================================
> /* IEEE positive infinity.  */
>
> #if __GNUC_PREREQ(3,3)
> # define INFINITY       (__builtin_inff())
> #else
> # define INFINITY       HUGE_VALF
> #endif
> ===================================

What are those quotations supposed to prove?

> IEEE != POSIX in general.

I am aware of that.

>> If your system headers only
>> define one of them, it is these which should be fixed, not
>> FFmpeg.
>
> Are you really, really sure in this? Cant you, please, be so kind
> to point me where POSIX and only POSIX stands for INFINITY *must*
> be defined?

The POSIX section on math.h
(http://www.opengroup.org/onlinepubs/009695399/basedefs/math.h.html)
makes it quite clear:

  The header shall define the following symbolic constants:
  [...]
  HUGE_VAL
    A positive double expression, not necessarily representable as a
    float. Used as an error value returned by the mathematics
    library. HUGE_VAL evaluates to +infinity on systems supporting
    IEEE Std 754-1985.

  HUGE_VALF
    A positive float constant expression. Used as an error value
    returned by the mathematics library. HUGE_VALF evaluates to
    +infinity on systems supporting IEEE Std 754-1985.

  HUGE_VALL
    A positive long double constant expression. Used as an error value
    returned by the mathematics library. HUGE_VALL evaluates to
    +infinity on systems supporting IEEE Std 754-1985.

  INFINITY
    A constant expression of type float representing positive or
    unsigned infinity, if available; else a positive constant of type
    float that overflows at translation time.
  [...]

The C99 spec requires the same constants, but is not as strict about
the actual values:

  The macro

    HUGE_VAL

  expands to a positive double constant expression, not necessarily
  representable as a float. The macros

    HUGE_VALF
    HUGE_VALL

  are respectively float and long double analogs of HUGE_VAL.

  The macro

    INFINITY

  expands to a constant expression of type float representing positive
  or unsigned infinity, if available; else to a positive constant of
  type float that overflows at translation time.

Convinced?

> And what do you suppose me to do? Write to OpenBSD development
> team?

Yes.

> They will likely reject this "fix",

Their loss, not mine.

> and even if they'll accept it, it will take ages to make update of
> all OpenBSD setups reasonable.

Does something mandate that your machine be the last one updated?

>> 2. HUGE_VAL is of type double, whereas INFINITY is of type
>> float. Using HUGE_VAL where a float is expected might not work
>> as expected.
>
> Well, this patch is not my own invention. It is used and works for
> ages at MPlayer, please look at libmpcodecs/ve_lavc.c. As shown in
> cite from math.h at OpenBSD earlier, HUGE_VAL is practically
> converted *char to *(double*) value, so I doubt there is some
> difference between double and float here.

Read the quoted text above.  It explicitly says that HUGE_VAL is not
necessarily representable as a float.  An IEEE double is 64 bits, and
a float is 32 bits, so there are by necessity certain double values
that cannot be represented by a float.

> If you insist, I may use HUGE instead.

Use WHAT instead?

>> 3. Aside from the above, this is the wrong place to add a
>> missing definition of INFINITY.
>
> Why? Have you a better idea?

Yes, fix your system.

> I will be glad to hear it.
> The only place where it is used in FFmpeg is nellymouserenc.c, so I
> assume it to be this file specific,

It is a STANDARD constant, in no way whatsoever specific to that file.

-- 
M?ns Rullg?rd
mans at mansr.com