[Ffmpeg-devel] HTTP probing issue... [PATCH]

[François Revol]

> Hi Francois,
> 
> On Feb 28, 2007, Francois Revol wrote:
> > That's what AVUNERROR() is about
> > it returns one of the posix error codes which you can pass to
> > strerror()
> > which should return an human readable string, possibly already
> > translated, not sure about this.
> 
> But that's still not contextual. There are no AVERROR codes to  
> separate between, for example, "file not found" (404/ENOFILE?) and  
> "authorization denied" or "permission denied" (403/EPERM), and so on  

My last reply should be enough but just in case:
Errors will not be only one of AVERROR_* since the AVERROR() change I 
made recently.
They can now be any POSIX error (actually some code does pass back 
errno through return value).
If some code like http doesn't return sensible enough errors you can 
always submit patches to return AVERROR(EWHATEVER) (as long as it's not 
too system specific).

> for many other cases. I agree that one could add more AVERROR_*s to  
> match up, but why then is there AVERROR_*? Why not just use errno.h  

AVERROR_* are kept for compatibility with code using them only.
They are now mapped to possible error values but not all of them.

> if we're trying to mimmick it? Is there some part where errno.h does  
> not suffice? I mean, given that there is apparently an exact mapping  
> from AVERROR_* to errno.h codes, that is presumably not the case...

I kept them for apps using them and tried to map to the closest posix 
error.
Some like "number required" weren't exactly it but as long as it 
matches what is returned for what it was it should be ok.

Clean app design should always check for unexpected errors anyway.

> It's really not about the effort, if people agree to drop AVERROR_*,  
> I (or anyone) could sed it out in a second. (And I'm also not trying  
> to flame, I am just intruiged by the idea of no longer needing to  
> hack in stuff to get contextual errors from lavf/lavio.)

Once more: Just forget about AVERROR_*.

Fran?ois