[FFmpeg-devel] libossupport status
Sat Dec 29 19:08:43 CET 2007
On Sat, Dec 29, 2007 at 12:09:18PM -0500, Ronald S. Bultje wrote:
> On Dec 29, 2007 6:59 AM, Fran?ois Revol <revol at free.fr> wrote:
> > > > And this way of returning errors is shamely reused in other things
> > > > like
> > > > OSS, up to apps. Even ffmpeg did that at some point (and still does
> > > > but
> > > > through a macro).
> > >
> > > It's hardly shameful.
> > It is.
> I want to fully support this one, becuase it doesn't allow very meaningful
> error reporting. A more proper way would be to use both error domains and
> codes (e.g. in a x<<16|y way, but it could also be a complete struct such as
> in glib). Reason is that we can only return system codes, not http error
> codes, host resolving problems, rtsp status messages or anything else. E* is
> severely limited, allowing multiple classes would be nice to have if people
> can agree on some specific implementation (e.g. -((1<<16)|abs(errno)) for
> system errors, -((2<<16)|http_error_code) for http errors etc., or
iam scared ...
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.
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel