[FFmpeg-cvslog] r14484 - in trunk/libavcodec: audioconvert.c audioconvert.h

[Måns Rullgård]

"Ivan Kalvachev" <ikalvachev at gmail.com> writes:

> On 8/3/08, Michael Niedermayer <michaelni at gmx.at> wrote:
>> On Sun, Aug 03, 2008 at 01:55:50PM +0100, M?ns Rullg?rd wrote:
>>> The Wanderer <inverseparadox at comcast.net> writes:
>>> 
>>> > Diego Biurrun wrote:
>>> >
>>> >> On Sat, Aug 02, 2008 at 02:55:30PM +0200, Diego Biurrun wrote:
>>> >> 
>>> >>> On Sat, Aug 02, 2008 at 12:12:11AM +0200, Michael Niedermayer
>>> >>> wrote:
>>> >>> 
>>> >>>> Would it be possible that you could spell out the rule you think
>>> >>>> is a rule so we all know beyond doubt if there are exceptions and
>>> >>>> if so which exactly.
>>> >>> 
>>> >>> All files should #include everything they need directly.
>>> >> 
>>> >> For system headers like inttypes.h that are documented to always
>>> >> #include other headers like stdint.h, I consider just inttypes.h enough.
>>> >
>>> > What about for non-system headers which are, or could be, "documented"
>>> > (that is, explicitly guaranteed) to always include particular other
>>> > headers - or, more to the point, provide particular symbols?
>>> 
>>> 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.
>
> I do not like it.
>
> 1. It doesn't allow declaration or definition to be in the same file
> (source or header) where it is used.

That was obviously not my intention.

> 2. The rule doesn't imply or limit inclusions to the necessary. You
> can fill headers with useless stuff, without breaking the rule.

You can always fill your files with useless stuff.  

> 3. The "indirect" inclusion is definitely huge step back.

A step back from what?  In what respect?

> 4. There is no need for all headers to be self sustained. I know this
> is the key to that system, but definition that says "... a file
> (source or header included by the source)..." would work just as well.

That would be a different rule, and one that I consider inferior,
because it leads to trouble.  Trust me, I've been there.

> Actually as long as we talk about definitions "... file (source)..." 
> is sufficient.
> This is because the trick is in the word "guaranteed".  As long as it
> is not explicitly defined the whole definition is pure academic
> exercise .

Apparently my rule was not safe against the most hardened trolls.
Let me try again:

  For each type, symbol, or macro referenced in a file (source or
  header), the file shall either:
  - contain a declaration or definition of the type, symbol, or macro,
  or
  - #include a header file documented to provide, directly or
    indirectly, a declaration or definition of the type, symbol, or
    macro.

Sorry for the patent-speak, but I want to avoid any possibly ambiguous
references.  At least I didn't use the word "plurality".

-- 
M?ns Rullg?rd
mans at mansr.com