[Ffmpeg-devel] More of the BeOS fixes...

François Revol revol
Fri Mar 9 10:13:34 CET 2007


> "Fran?ois Revol" <revol at free.fr> writes:
> 
> > This is my current diff against trunk.
> > The recent removal of PRI* and *INT64_C broke the BeOS build, and 
> > as 
> > some of you probably noticed, I got quite pissed off at it after 
> 
> The pissed-off-ness is somewhat mutual.

I didn't break the build.
Still...

> > Index: configure
> 
> OK
> 
> > Index: libavutil/internal.h
> > [...]
> > +#    ifndef PRId64
> > +#    define PRId64 "lld"
> > +#    endif
> > [...]
> > +#ifndef INT64_C
> > [...]
> 
> Rejected for reasons explained ad nauseum.

I yet have to see a valid reason for this.
Those things are an after-thought addition to standards, that came in 
way after some OSes shipping date.
You can't expect those OSes to fix their header because some dumb 
standard appeared 5 years later. That's a bad standard. A correct 
correct would have dictated using default values for the platform in 
existance before it.
Anyway, I won't back that one up.

There is no reason to start floating fake headers for mingw, beos, 
riscos and whatever when a single default could be provided.
I don't think the misbehaviours that were refered to actually happen on 
those regular 32bit platforms we used for 20 years. 64bit platforms are 
recent enough for OSes running on them to be actively maintained 
anyway, appart alpha.

> 
> > Index: libavformat/os_support.c
> > ===================================================================
> > --- libavformat/os_support.c	(revision 8296)
> > +++ libavformat/os_support.c	(working copy)
> > @@ -78,7 +78,7 @@
> >  #if !defined(HAVE_INET_ATON) && defined(CONFIG_NETWORK)
> >  #include <stdlib.h>
> >  #include <strings.h>
> > -#include "barpainet.h"
> > +#include "network.h"
> >
> >  int inet_aton (const char * str, struct in_addr * add)
> >  {
> 
> Probably OK.

Hope so. It was the reason for it.

> 
> > Index: libavformat/udp.c
> > ===================================================================
> > --- libavformat/udp.c	(revision 8296)
> > +++ libavformat/udp.c	(working copy)
> > @@ -394,6 +394,7 @@
> >      }
> >  #endif
> >
> > +#ifdef SO_SNDBUF
> >      if (is_output) {
> >          /* limit the tx buf size to limit latency */
> >          tmp = UDP_TX_BUF_SIZE;
> > @@ -402,6 +403,7 @@
> >              goto fail;
> >          }
> >      }
> > +#endif
> >
> >      s->udp_fd = udp_fd;
> >      return 0;
> 
> OK.  I don't suppose there are systems where SO_SNDBUF is an enum or
> something.

IIRC the IPPROTO_* are meant to be cpp-checkable but I don't remember 
about those.

> 
> > Index: libavformat/network.h
> > ===================================================================
> > --- libavformat/network.h	(revision 8296)
> > +++ libavformat/network.h	(working copy)
> > @@ -24,7 +24,22 @@
> >  #include <sys/types.h>
> >  #include <sys/socket.h>
> >  #include <netinet/in.h>
> > +#ifdef HAVE_ARPA_INET_H
> >  #include <arpa/inet.h>
> > +#else
> > +#    if !defined(HAVE_INET_ATON)
> > +/* in os_support.c */
> > +int inet_aton (const char * str, struct in_addr * add);
> > +#    endif
> > +#endif
> 
> The existence of arpa/inet.h and inet_aton are independent.

Right, they are supposed to be declared in, but some other OS probably 
declare it elsewhere...
Thing is the configure check is actually broken on BeOS-BONE, because 
it is actually __inet_aton, so it fails to link to it while it actually 
exists. I can probably fake the check instead in configure.

> 
> >  #include <netdb.h>
> >
> > +#if !defined(IP_ADD_MEMBERSHIP)
> > +/* just so structs have a storage size */
> > +struct ip_mreq {
> > +    struct in_addr imr_multiaddr;  /* IP multicast address of 
> > group */
> > +    struct in_addr imr_interface;  /* local IP address of 
> > interface */
> > +};
> >  #endif
> 
> This is bad.  Whatever uses that struct should be conditionally
> compiled, as it can't possibly work with a fake definition like this.

The code is actually ifdefed out, but not the ip_mreq member of the 
context struct. So it's declared even if unused. I didn't find 
#ifdeffing struct members really sane, but I suppose it won't give a 
bin compatibility problem.

Fran?ois.




More information about the ffmpeg-devel mailing list