[FFmpeg-devel] libossupport status

[Rich Felker]

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
abstracted away.

> 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 :)

Not interested.

Rich