[FFmpeg-devel] [PATCH] Bunch of accumulated patches...

Måns Rullgård mans
Tue Jan 15 03:20:51 CET 2008

Rich Felker <dalias at aerifal.cx> writes:

> On Tue, Jan 15, 2008 at 01:47:27AM +0100, Michael Niedermayer wrote:
>> > Ah yeah I forgot the positivity requirement. So negative values makes
>> > it easy to define your own errors.
>> functions in libav* return negative ints as errors
>> we will not change all int return types to long long (because its inefficient
>> on 32bit archs), so the positivity vs. negativity doesnt help
>> this leaves 4 obvious options
>> 1. drop all usage of POSIX E*
> This would probably be my preference.

I'm tempted to agree.

>> 3. just pick random values for our extra error codes, theres a
>>    philosophical collision possibility
> While this would probably work in practice unless someone
> intentionally designed a nasty system to clash with it, it's ugly and
> hackish beyond all imagination..

Need I remind you of Murphy's law?

>> 4. add a check to configure to choose unused E* (this is easy by using
>>    strerror())
> Are you sure? strerror returns a string for unknown errors, and the
> string it returns is implementation-defined. I don't see how it can
> help you identify which error values are unused.

Reading the spec:

  strerror() shall map any value of type int to a message.
  On error errno may be set, but no return value is reserved to
  indicate an error.

This can't be used to determine which values are used as error codes
in the system.  There is also the issue of codes being added through a
libc upgrade after the test was performed.

M?ns Rullg?rd
mans at mansr.com

More information about the ffmpeg-devel mailing list