[FFmpeg-cvslog] r14484 - in trunk/libavcodec: audioconvert.c audioconvert.h
Michael Niedermayer
michaelni
Sun Aug 3 18:51:47 CEST 2008
On Sun, Aug 03, 2008 at 05:51:10PM +0200, Diego Biurrun wrote:
> On Sun, Aug 03, 2008 at 05:24:19PM +0200, Michael Niedermayer wrote:
> > On Sun, Aug 03, 2008 at 01:55:50PM +0100, M?ns Rullg?rd wrote:
> > >
> > > Same thing. Let me try to state exactly what I want the rule to be:
> > >
> > > For each type, symbol, or macro used in a file (source or header),
> > > the file shall contain an #include line guaranteed to provide,
> > > directly or indirectly, a declaration or definition of the type,
> > > symbol, or macro.
> > >
> > > Is this unambiguous enough?
> >
> > Yes, thank you!
> >
> > I do not want to make a premature statement but i think this suggestion
> > would be acceptable.
> > Though it is certainly not what diego suggested nor how i understood
> > your previous mails.
>
> It is what I suggested, or at least tried to.
>
> We just need to clarify what indirectly providing means.
with slightly different wording:
"It is what I suggested, or at least tried to.
We just need to redefine what indirectly providing means."
id belive it.
> It should be
> something like "A is documented to provide B
Theres nothing wrong with documenting it and iam all for documenting
it, but
> and this will never change".
the word "never" is not appropriate, headers change, internal headers
even more so, and if no file including a header needs an #include anymore
it should be droped.
Similarly if only 1 file including a header needs something that could
be moved to that 1 file. Both these contradict the "never"
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I count him braver who overcomes his desires than him who conquers his
enemies for the hardest victory is over self. -- Aristotle
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/attachments/20080803/24bd1cc0/attachment.pgp>
More information about the ffmpeg-cvslog
mailing list