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

Marc Mason mpeg.blue
Fri Jan 16 10:32:20 CET 2009


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).

Would you agree with these statements ?
Are there other places where uint32_t is necessary ?

I propose another (only compile-tested) trivial patch :-)

-- 
Regards.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: avidec-unsigned-int.diff
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090116/382265c3/attachment.txt>



More information about the ffmpeg-devel mailing list