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

[Aurelien Jacobs]

M?ns Rullg?rd wrote:

> 
> 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.

Another solution is probably to define _SVID_SOURCE. I'm not sure if this
is really better than _BSD_SOURCE, but that's what my feeling would tell me
to do.

Aurel