[FFmpeg-devel] uint32_t arg and %X conversion specifier

Michael Niedermayer michaelni
Fri Jan 16 14:41:57 CET 2009


On Fri, Jan 16, 2009 at 10:32:20AM +0100, Marc Mason wrote:
> M?ns Rullg?rd wrote:
>> Marc Mason wrote:
>>> Michael Niedermayer wrote:
>>>> Marc Mason wrote:
>>>>> M?ns Rullg?rd wrote:
>>>>>> Marc Mason wrote:
>>>>>>
>>>>>>> I see two ways to fix the following (very minor) warning.
>>>>>>>
>>>>>>> avidec.c:428: warning: format '%X' expects type 'unsigned int', but
>>>>>>> argument 4 has type 'uint32_t'
>>>>>>>
>>>>>>> 1) cast the arg to unsigned long
>>>>>>> http://home.att.net/~jackklein/c/inttypes.html#long
>>>>>>> drawback : on platforms where long are 64-bits wide, this will push 4
>>>>>>> useless ( == 0 ) octets
>>>>>> One could cast to unsigned int too.
>>>>>
>>>>> I don't think so.
>>>>>
>>>>> Consider a platform where
>>>>> sizeof(unsigned int)  = 16 bits
>>>>
>>>> isn't allowed by POSIX and our code wouldn't work there anyway.
>>>
>>> I was not aware of that. Thanks for bringing it to my attention.
>>>
>>> http://www.opengroup.org/onlinepubs/9699919799/basedefs/limits.h.html
>>>
>>> {UINT_MAX}
>>>     Maximum value for an object of type unsigned.
>>>     [CX] Minimum Acceptable Value: 4 294 967 295
>>>
>>> Thus the first patch has a variant.
>> Both explicitly sized types and casts are things that should only be
>> used when necessary.  Does the offending variable really need to be
>> uint32_t in the first place?
>
> Since POSIX requires unsigned int to be at least 32-bits wide, it seems 
> safe (??) to use unsigned int in most places where uint32_t is used.
>
> uint32_t would only be needed when one needs *exactly* 32 bits, for example 
> in structures that have a precise size (as in a structure representing an 
> IPv4 header, or an RTP header).

code using >>, division and modulo or even a
a+=b; if(a)

behave differently if the variables have more bits

+ - * << & | ^ alone are safe against having extra bits, though of course
operations that depend on the extra bits like a < or <=, ... need some
care


>
> Would you agree with these statements ?
> Are there other places where uint32_t is necessary ?
>
> I propose another (only compile-tested) trivial patch :-)

ok if it passes regression tests, it should but well untested changes always
break something ;)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090116/22452f29/attachment.pgp>



More information about the ffmpeg-devel mailing list