[FFmpeg-devel] [PATCH] use standard integer types in libavdevice/bktr.c

[Reimar Döffinger]

On Sat, May 30, 2009 at 04:13:51PM +0400, Michael Kostylev wrote:
> 
> On Fri, 29 May 2009 17:43:16 +0100
> M?ns Rullg?rd wrote:
> 
> >>>> libavdevice/bktr.c uses the BSD (?) variants like u_int64_t of standard
> >>>> integer types like uint64_t.  Here is a patch to change the file to the
> >>>> standard types that we use in other places, which I think is desirable.
> >>>> It's not compile-tested since I do not have access to a BSD system, but
> >>>> it should be trivial.
> >>> That file will only be used on BSD systems, so I don't see a problem.
> >>> The headers probably already use the BSD types, and mismatches might
> >>> result in compiler warnings (or worse).
> >> bktr.c really includes the headers containing the BSD types which typedefs
> >> may be protected by some specific macros like __BSD_VISIBLE on FreeBSD and
> >> _NETBSD_SOURCE on NetBSD. __BSD_VISIBLE is zeroed and _NETBSD_SOURCE is
> >> undefined when _POSIX_C_SOURCE is defined.
> >> FreeBSD:
> >> /usr/include/dev/bktr/ioctl_meteor.h:53: error: expected specifier-qualifier-list before 'u_short'
> >> /usr/include/dev/bktr/ioctl_meteor.h:61: error: expected specifier-qualifier-list before 'u_long'
> >> /usr/include/dev/bktr/ioctl_meteor.h:70: error: expected specifier-qualifier-list before 'u_long'
> >> /usr/include/dev/bktr/ioctl_bt848.h:94: error: expected specifier-qualifier-list before 'u_char'
> >> /usr/include/dev/bktr/ioctl_bt848.h:195: error: expected specifier-qualifier-list before 'u_int'
> >> Btw, the IPPROTO_IPV6 macro is also protected by #if __BSD_VISIBLE:
> >> ...libavformat/udp.c:77: error: 'IPPROTO_IPV6' undeclared (first use in this function)
> >> NetBSD:
> >> /usr/include/dev/ic/bt8xx.h:60: error: expected specifier-qualifier-list before 'u_short'
> >> /usr/include/dev/ic/bt8xx.h:68: error: expected specifier-qualifier-list before 'u_int'
> >> /usr/include/dev/ic/bt8xx.h:77: error: expected specifier-qualifier-list before 'u_int'
> >> /usr/include/dev/ic/bt8xx.h:287: error: expected specifier-qualifier-list before 'u_char'
> >> /usr/include/dev/ic/bt8xx.h:388: error: expected specifier-qualifier-list before 'u_int'
> > So the headers are buggy. 
> 
> It doesn't matter. The "bug", which was introduced as a feature, is already
> released. The question is whether two extra add_cflags will make configure
> uglier.

You mean _globally_? That would mean polluting the namespace and risking
compilation problems on those systems who did it right without
breaking their headers in favour of supporting brokenness.
No, I don't consider that an acceptable compromise.
And also I can't see how bktr.h being impossible to compile as C99 code
could be considered a feature (this compilation error after all happens
also when compiling only bktr.h, no other code being involved at all).
Adding defines to bktr.c I wouldn't mind much, but I very much request
that a bug report is filed upstream (and it is made sure they don't
close it with "wontfix" just because they think it is acceptable to
litter every program with BSD-specific hacks - they are not a bit better
than all those GNUisms).
The fact that every BSD variant seems to need different defines to make
bktr.h compile also adds to the fun, a bit of cooperation really
wouldn't hurt (to make this work we need to define _BSD_SOURCE,
__BSD_VISIBLE, _NETBSD_SOURCE and what else? And in the next round maybe
we need a _FREEBSD_SOURCE, _DRAGONBSD_SOURCE, _SOME_IDOTS_BSD_SOURCE and
have more defines than code? To get exactly the same thing?
What kind of idiocy is that?).
And what is that "is already released" argument supposed to be? Are they
releasing and storing on stone tables? Otherwise a fix can be backported.

> For comparison, take a look how someone is reinventing the system
> headers:
> http://groups.google.com/group/mailing.freebsd.ports-bugs/msg/85eaeb7fbd97ad49

A worse patch is not a great argument for a bad patch.
So, sorry for the flames, but maybe they help you understand that (and
maybe why) we are quite pissed and want to see some effort to get things
fixed (at the place we think is broken) instead of just adding hacks to _our_ code,
that _we_ have to maintain.

Greetings,
Reimar D?ffinger