[Ffmpeg-devel] Compiler warnings

Måns Rullgård mru
Fri Feb 3 09:22:53 CET 2006

Rich Felker <dalias at aerifal.cx> writes:

> On Thu, Feb 02, 2006 at 12:46:44PM +0100, Erik Slagter wrote:
>> On Thu, 2006-02-02 at 11:15 +0000, M?ns Rullg?rd wrote:
>> > >> I can think of cases where a signed/unsigned difference could cause
>> > >> unexpected behavior, but these are rare.
>> > >
>> > > Grmbl. If char's would have been unsigned by default, since the
>> > > beginning, imho this "warning" problem wouldn't have been there at all.
>> > > What would have driven the person that invented this? :-(
>> > 
>> > The cases I was thinking of are not limited to 8-bit types.
>> > Anything involving arithmetic on numbers with the top bit set can
>> > give strange results if the signed and unsigned types are mixed.
>> Yes, you're right, but the "char" case is the most disturbing one and
>> also the one that generates most warnings. IMHO mixing signed and
>> unsigned ints, shorts, longs is always questionable.
> IMO it's not questionable at all if the programmer knows what they're
> doing. Signed is a property of a comparison operator, not an inherent
> property of a number. C just tacks it onto the type in order to
> automatically select which type of comparison operator to use (also
> which type of right bitshift and promotion to larger types).

Nothing is questionable if the programmer knows what he's doing.
Warnings are there to catch the cases when he does things by mistake.

> Anyway since when is this a warning? I've never gotten signed/unsigned
> mismatch warnings with -Wall, and IIRC I remember reading in the gcc
> manual that the gcc developers refuse to make signed/unsigned warnings
> part of -Wall because they're always nonsense.

It's enabled by -Wextra (-W in older versions) along with a bunch of
other nonsense.

M?ns Rullg?rd
mru at inprovide.com

More information about the ffmpeg-devel mailing list