[FFmpeg-devel] libossupport status

Rich Felker dalias
Sat Dec 29 22:10:09 CET 2007

On Sat, Dec 29, 2007 at 07:08:43PM +0100, Michael Niedermayer wrote:
> iam scared ...

Me too.

> A simple standard list of error codes with some reserved range for the user
> is more than sufficient.
> What the standards fail at, is that they dont mandate specific values for each
> E*, that would make handling missing E* MUCH simpler. It also would allow
> passing E* between different systems, over a network for example ...
> Also the existing list of POSIX E* is badly insufficient for many uses.

They can be exchanged over a network perfectly well, as text. One
could also design a set of 'standard' network numbers for each
standard error value E*. On the other hand, POSIX's job is to codify
existing practice and what's common between operating systems (or can
be made common without horrible breakage of existing implementations),
not to mandate redesigning all OS's into a common OS, so such a set of
values would be outside the scope of POSIX. Anyway, almost all of the
E* errors are inappropriate for reporting to a remote peer as-is. Some
are useful but many are unhelpful or even lead to information leaks
that could aid attackers.

Sane error handling is really not that hard. Simple apis with no
persistent state should not have more than a few trivial error codes,
and should return error status via the return value. An api with more
detailed error reporting requirements and/or persistent state needs to
be using an instance object of some sort, and storing all the details
of the error status in the object. This avoids reentrancy issues and
also makes it easier for the caller to decide how little or how much
condition-specific error handling it cares to do. In cases where both
system errors and input-specific errors are possible, the api should
have its own error code that means "system error" and either store the
value of errno in a separate part of its state of expect the caller to
inspect errno right away.


More information about the ffmpeg-devel mailing list