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

Måns Rullgård mans
Tue Jul 14 14:11:21 CEST 2009


Martin Storsj? <martin at martin.st> writes:

> 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()))?

Simpler, just have ff_neterrno() return a sanitised code directly.

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

Are there such codes?

-- 
M?ns Rullg?rd
mans at mansr.com



More information about the ffmpeg-devel mailing list