On Thu, Mar 20, 2008 at 08:13:47AM +0100, Diego Biurrun
wrote:
> On Wed, Mar 19, 2008 at 01:28:25PM +0100, Reimar
Döffinger wrote:
> > On Wed, Mar 19, 2008 at 11:49:13AM -0000, Måns
Rullgård wrote:
> > > A more realistic example is a file, let's
call it mpeg12data.c, that includes,
> > > say, rational.h, and everything is fine. One
fine day, someone changes
> > > rational.h to require stuff from common.h,
without adding the #include
> > > line. Suddenly, mpeg12data.c fails to
compile because it doesn't include
> > > common.h, and has no reason to do so, not
directly using any of its symbols.
> >
> > I do not consider (esp. one-time) compilation
errors a big deal.
> > Either way I do not strongly favour either way, I
just think that
> > headers-including-headers has a higher probability
of "silent" failures,
>
> What kind of silent failures would that be?
What I gave before, that code was tested with some other
header that
included common.h and the breaks due to e.g. WORDS_BIGENDIAN
never being
defined when this header stops including it.
Of course forgetting a critical header is possible in all
cases, it is
just more likely that it will result in compilation error if
headers do
not include things themselves.
Though adding a rule on top of always including config.h or
common.h or
something that will make sure this can not happen would work
too.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
|