[FFmpeg-devel] [PATCH][RFC] -std=c99

Måns Rullgård mans
Thu Aug 21 12:16:09 CEST 2008

Luca Abeni wrote:
> Hi all,
> Luca Abeni wrote:
> [...]
>>>  Does anyone know a standardised way of doing whatever this code does?
>> I cannot speak about standards, but it seems to me that this is the same
>> code used by all the other programs that need to join multicast groups
>> and/or to receive/send multicast traffic.
>> I cannot reproduce the build failure here, but maybe the problem can be
>> fixed by defining _BSD_SOURCE at the top of the file?
> Ok, I studied the problem a little bit more, and:
> 1) IPv4 multicast does not seem to be standardised in POSIX, single unix
>     specification, & friends (only IPv6 multicast seems to be standard!)
> 2) however, IPv4 multicast is supported by BSD systems
> 3) in a recent "namespace cleanup" glibc removed some of the definitions
>     needed for IPv4 multicast, unless the user is asking for GNU extensions,
>     BSD compatibility, or System V
>     However, this removal has been done in a funny way: the ip_mreq structure
>     is not defined, but IP_ADD_MEMBERSHIP is still defined. I call this
>     "funny" because setsockopt(IP_ADD_MEMBERSHIP) always wants a parameter
>     of type ip_mreq, so I think it does not make any sense to define
>     IP_ADD_MEMBERSHIP if ip_mreq is not provided (BTW, this is the reason
>     why the compilation is failing).
>     The first libc affected by this funny behaviour should be 2.8.
> 4) I believe that adding "#define _BSD_SOURCE" at the top of udp.c (before
>     all the "#include"s) should fix the compilation (can anyone test? I do
>     not see the compilation failure, so I cannot test). And asking fro BSD
>     compatibility when using sockets looks like a good idea, so I think
>     this could be an acceptable solution...
> Ideas/comments?

It seems this is the only sensible option we have.  The one thing I don't
like about it is that by messing with reserved namespace (_BSD_SOURCE),
we are invoking undefined behaviour.  There is no telling what some other
libc might do if this is defined.  In reality, the risk of something nasty
happening is probably quite low.

M?ns Rullg?rd
mans at mansr.com

More information about the ffmpeg-devel mailing list