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

[Måns Rullgård]

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