[FFmpeg-cvslog] r11211 - trunk/libavcodec/i386/dsputil_mmx.h
Måns Rullgård
mans
Wed Dec 19 00:06:30 CET 2007
Diego Biurrun <diego at biurrun.de> writes:
> On Tue, Dec 18, 2007 at 09:50:02PM +0100, Aurelien Jacobs wrote:
>> Diego Biurrun wrote:
>>
>> > On Wed, Dec 12, 2007 at 11:45:03PM +0100, aurel wrote:
>> > >
>> > > Log:
>> > > add required include to make this file self-contained
>> > >
>> > > --- trunk/libavcodec/i386/dsputil_mmx.h (original)
>> > > +++ trunk/libavcodec/i386/dsputil_mmx.h Wed Dec 12 23:45:03
>> > > 2007 @@ -22,6 +22,8 @@
>> > > #ifndef FFMPEG_DSPUTIL_MMX_H
>> > > #define FFMPEG_DSPUTIL_MMX_H
>> > >
>> > > +#include <stdint.h>
>> > > +
>> > > extern const uint64_t ff_bone;
>> > > extern const uint64_t ff_wtwo;
>> >
>> > Isn't inttypes.h more portable and thus preferable?
>>
>> $ find ffmpeg -name '*.h' -exec grep -H stdint.h {} \; | wc -l
>> 70
>
> I am aware that we already use stdint.h in a lot of places. Still it
> could make sense to switch to inttypes.h where possible if it is more
> portable.
The key being IF. There exist, or have existed, systems lacking one,
the other, or both of these headers. Current systems would seem to
have either none or both, so there really isn't much to be gained from
choosing one over the other from this point of view.
However, inttypes.h is a superset of stdint.h, and I consider it good
practise to #include the minimal set of headers required. If nothing
else, doing so makes compilation faster, if only by a little.
--
M?ns Rullg?rd
mans at mansr.com
More information about the ffmpeg-cvslog
mailing list