[FFmpeg-devel] [PATCH] Use ff_neterrno instead of errno in tcp.c

[Martin Storsjö]

On Tue, 14 Jul 2009, M?ns Rullg?rd wrote:

> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > On Tue, Jul 14, 2009 at 11:03:59AM +0300, Martin Storsj? wrote:
> >> 
> >> The attached patch gives better consistency; if ff_neterrno() is checked 
> >> instead of errno, that's probably what should be used in the return value, 
> >> too. (On windows, network errors aren't visible in errno.)
> >
> > are the values of ff_neterrno compatible with errno values ?
> > if yes the patch is obviously correct if no then there may be a problem
> 
> On real OSes ff_neterrno *is* errno.  On the others, this change can't
> make things any worse...  I share your concern though.

They're not fully compatible. The winsock headers define the official 
winsock error codes, which are in the range 10000->, e.g. WSAEINTR = 
10004. Errno.h defines the normal ones in the range 1->, e.g. EINTR = 4.

So for a caller checking the return value against AVERROR(E*), it won't 
match the expected values - callers on windows that want to check for 
different errors would need to check AVERROR(WSAE*) additionally.

But as M?ns points out, this doesn't make things any worse at least, and 
doesn't affect other OSes. (Earlier it probably would have returned 0, 
since errno didn't know about the socket errors.)


Would it be better to define some inverse of FF_NETERROR, that maps the 
values back to the expected range? E.g.

#define FF_NET_UNERROR(x) ((x) - WSABASEERR)

And then return AVERROR(FF_NET_UNERROR(ff_neterrno()))?

But mapping them this way obfuscates the case when the error is a 
winsock-specific error code, where the original value would be more 
helpful than some mangled value mapping to nothing at all.

// Martin