[FFmpeg-devel] [PATCH] Avoid-compiler-warning-unary-minus-operator-applied

Nicolas George nicolas.george at normalesup.org
Sun Apr 15 10:24:37 CEST 2012

Le sextidi 26 germinal, an CCXX, Robert Nagy a écrit :
> I guess
> #define AVERROR(e) (-((int)e))
> Would be the valid syntax?

More or less. "(int)value" is the proper syntax for casts. But for macros,
you almost always need the put parentheses on the argument variable itself,
because it could be a complex expression with lower priority than a case.
And the parentheses between the cast and the minus are unneeded. Therefore,
a correct syntax would be (-(int)(e)).

Now, concerning the core of your suggestion, three points:

First, taking the opposite of an unsigned integer is a perfectly valid and
supported operation, since unsigned integers have a group structure. That
kind of construct is often used for rounding. Therefore, a warning about
that is just plain wrong.

Second, errno and the E* system values are explicitly defined to have type
int, therefore, the change to AVERROR should not be needed. Did you have a
problem with that particular macro?

Third, MKTAG really produces unsigned ints since commit 6b34fbba, and you
have therefore uncovered a real bug: casts from large unsigned to ints are
an undefined behaviour.

In fact, the last point is not just theoretical, look at that piece of code:

int64_t avio_seek(AVIOContext *s, int64_t offset, int whence)
	if (s->eof_reached)
	    return AVERROR_EOF;

AVERROR_EOF is cast to an int64_t as an unsigned, and therefore ends up as a
large positive int64_t.

I'll to make a small piece of code exhibiting the problem.


  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120415/2378d31f/attachment.asc>

More information about the ffmpeg-devel mailing list