[FFmpeg-devel] [PATCH][RFC] -std=c99
Thu Aug 21 16:05:11 CEST 2008
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
More information about the ffmpeg-devel