[FFmpeg-cvslog] r14484 - in trunk/libavcodec: audioconvert.c audioconvert.h
The Wanderer
inverseparadox
Sun Aug 3 17:54:44 CEST 2008
M?ns Rullg?rd wrote:
> The Wanderer <inverseparadox at comcast.net> writes:
>
>> Diego Biurrun wrote:
>>> 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, though it seems a little inconsistent with the previous statement,
because the "or indirectly" could easily cover a multitude of sins.
If that rule is accepted, then the discussion becomes a matter of how
and where to set the guarantees.
As I have indicated in the past, I might consider the fact that a header
associated with a particular source file uses a particular symbol in a
prototype of a function defined in that source file to constitute a
guarantee that the header will provide a definition of that symbol for
as long as the source file in question needs it, and therefore that the
source file does not need to include any other header to provide that
symbol. (That's a fairly dense sentence, but any less dense way I've
tried seems more ambiguous.) At the same time, another source file which
does not define that same function would not necessarily have the same
guarantee that the header will always provide that symbol.
I can easily see how others might disagree about whether this would
actually constitute a "guarantee" in this context. At this point, that
is precisely the sort of thing which would need to be discussed and
settled on.
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Secrecy is the beginning of tyranny.
More information about the ffmpeg-cvslog
mailing list