[FFmpeg-devel] [PATCH] Fix compilation on OpenBSD
Måns Rullgård
mans
Tue Nov 18 12:35:48 CET 2008
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
More information about the ffmpeg-devel
mailing list