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

Benoit Fouet benoit.fouet
Fri Jan 16 15:04:31 CET 2009


Hi,

On 01/16/2009 02:41 PM, Michael Niedermayer wrote:
> 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 ;)
>
>   

it does pass, so I applied it.

Ben





More information about the ffmpeg-devel mailing list