[FFmpeg-devel] libossupport status
Sat Dec 29 04:45:55 CET 2007
On Sat, Dec 29, 2007 at 03:26:15AM +0100, Fran?ois Revol wrote:
> > On Sat, Dec 29, 2007 at 02:35:55AM +0100, Fran?ois Revol wrote:
> > > Just like with this return -EFOO thing. It's an Unixism that should
> > > die
> > Unix does no such thing. RTFM POSIX/SUSv3. Error codes are in errno,
> > not returned at all, which is admittedly also brain-damaged (global
> > state) but a completely different issue.
> It doesn't do it publically, but does it internally in the code, so
> does Linux.
Unix is a standard, not an implementation, and therefore there is no
such thing as "what it does internally in the code". The syscall
calling convention is utterly irrelevant since it's completely
> 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.
> The global errno isn't such an issue, even BeOS works around it by
> #defining it to (*_errnop()) which returns the address of a TLS entry,
> and an exported global sticks there for single thread apps that insists
> on declaring it themselves.
> I think glibc does that too now.
Yes it is a problem. The idea that global state is acceptable and that
threading is the only reason it becomes a problem is completely
misguided and ignorant.
> Granted it could have been simpler to just return the error from
> syscalls instead of -1, which BeOS does for native calls (returns EFOO
> as status_t).
> It maintains a single error namespace with posix ones being a subset of
> them, and strerror() handles them all.
> You are welcome to use Haiku and contribute :)
More information about the ffmpeg-devel