On date Wednesday 2011-04-20 11:26:02 -0400, Ronald S. Bultje wrote: > Hi, > > On Wed, Apr 20, 2011 at 8:57 AM, Anton Khirnov <an...@khirnov.net> wrote: > > On Mon, 18 Apr 2011 13:35:48 +0200, Stefano Sabatini > > <stefano.sabatini-l...@poste.it> wrote: > >> [adding libav-devel to recipients, as this concerns API/ABI compatibility] > >> > >> On date Saturday 2011-04-16 19:12:34 +0200, Nicolas George encoded: > >> > Le septidi 27 germinal, an CCXIX, Stefano Sabatini a écrit : > >> > > * implement AVERROR_EOF as a libav* specific error code, rather than > >> > > mask the EPIPE POSIX error code which has a different semantics > >> > > > >> > > * implement AVERROR_INVALIDDATA as a libav* specific error code > >> > > (already > >> > > implemented but it was controversial), and fix the > >> > > AVERROR(EINVAL)/AVERROR_INVALIDDATA conflict > >> > > >> > Seems reasonable. > >> > > >> > > * drop AVERROR_NUMEXPECTED (not very important, but I believe it is a > >> > > too much specific error code, so I'd prefer to replace it with > >> > > AVERROR(EINVAL) > >> > > >> > A more generic AVERROR_SYNTAX could be possible too. > >> > > >> > > |bumping it to 51 will changes the codes returned by all libs using > >> > > libavutil > >> > > |all of them would need to bump major. > >> > > |i dont think this is reasonable, thus we should undo all error > >> > > redefinitions > >> > > |before they become real and debian burns you at the stake > >> > > > >> > > but I don't think this is a real issue (assuming that all the libav* > >> > > major versions are bumped at the same time), and this is my argument: > >> > > >> > I think the point is precisely in your parentheses: changing the error > >> > codes > >> > requires bumping the major version for all the libraries, not just > >> > libavutil. > >> > > >> > >> > One thought in passing: If the error codes get changed, it may be a good > >> > idea to adapt the definition of AVERROR(errno) to something like: > >> > > >> > #define AVERROR(e) (-(e) - 1) > >> > > >> > This would have the benefit that when some old piece of code returns -1 > >> > instead of a meaningful error code, it would not displayed as "Permission > >> > denied" or whatever errno code is 1 on this particular platform. > >> > >> I'd prefer to just return the negated POSIX error code, and avoid > >> other weird mapping. > >> > >> Possibly we could introduce an AVERROR_GENERIC code and replace -1 > >> with it, not that I like the idea too much. > >> > >> In attachment an updated patchset. > > > > The first three look sane to me, not sure about the point of the last, > > but if you think it's better... > > I don't think it's better TBH. Way too complex. Let's keep this stuff > simple...
The main point was to make easy to write the test, withuout to duplicate the code<->string mapping. Other options: * iterate through the list of error codes rather than do a binary search, simpler, slower * use an av_tree which is filled during init, should be more robust as the table doesn't need to be alread sorted, *but* would require an avutil_init(), so looks overkill * duplicate the code<->tag<->string mapping for the test program. As for the test program, this is mainly useful as a testing/debugging device, as it allows to show you the abovementioned mapping. Note that the last patch is the least important since it hasn't API/ABI implication, and can be safely applied later (in whatever form). I'm updating the patchset, will post as separate mails soon. -- If it pours before seven, it has rained by eleven. _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
