[FFmpeg-devel] FFmpeg and Solaris: offset_t conflict

[Diego Biurrun]

On Fri, Oct 03, 2008 at 10:30:06AM +0100, M?ns Rullg?rd wrote:
> 
> Diego Biurrun wrote:
> > On Fri, Oct 03, 2008 at 12:26:08AM +0100, M?ns Rullg?rd wrote:
> >> flameeyes at gmail.com (Diego 'Flameeyes' Petten?) writes:
> >>
> >> > Under solaris the offset_t type is actually declared by the system
> >> > headers, which means that the definition in FFmpeg itself is redefining
> >> > a system type.
> >> >
> >> > I have no idea why it does not have an ff_ prefix, but I think it should
> >> > have; unfortunately this change would break API since the offset_t file
> >> > would be disappearing on Linux and other OSes and subtly change under
> >> > Solaris.
> >> >
> >> > I'm not attaching a patch since it would be 61k and I'm not sure what
> >> > the best course of action would be for this. For what matters, the
> >> > change can be generated with a simple GNU sed command line:
> >> >
> >> > sed -i -e 's:\<offset_t\>:ff_offset_t:g' libavformat/*.{c,h}
> >>
> >> Something clearly needs to be done.  Is there any reason for not using
> >> int64_t directly?  Gratuitous use of typedef only makes code harder to
> >> read.
> >
> > Can't we check for it and typedef it conditionally similar to what we do
> > for socklen_t?
> 
> Since offset_t is not a standard type, an existing typedef could be
> anything. Our typedef is *always* int64_t, so simply using int64_t
> directly is by far the simpler solution.
>
> The name offset_t is easily confused with the standard off_t type,
> adding further weight to the argument against using it at all.  Lastly,
> *_t is POSIX reserved namespace if any POSIX header is included.

And I had indeed confused the two, so I'm all in favor for doing away
with the typedef as well.  I'll commit something in a moment.

Diego