[FFmpeg-devel] [PATCH] Set frame rate on v4l2 devices

José Miguel Gonçalves jose.goncalves
Mon Sep 13 16:28:15 CEST 2010


On 09/13/2010 02:35 PM, M?ns Rullg?rd wrote:
> Jos? Miguel Gon?alves<jose.goncalves at inov.pt>  writes:
>    
>> I agree with you. For this specific ioctl it would be better to treat
>> non-zero as an error.
>>
>> Bottom line. I think it's always better to consider an error
>> everything else that is not considered OK.
>>      
> The question is always what return values to expect on success and how
> to differentiate them from errors.  For example, the read() system
> call can perfectly legitimately return (ssize_t)(1u<<31), which would
> normally look like a negative number (the result if the (size_t) size
> argument is greater than SSIZE_MAX is implementation-defined).
> Treating all negative return values as errors would be incorrect on
> systems where a larger size is allowed.  The correct way is to check
> for (ssize_t)-1 and cast anything else to size_t before using it as
> usual.
>
>    

This is a theoretical problem... while possible, I think no one in it's 
good sense will make a 2 GB read() call.
Even considering an application/system were this would be possible, it 
will only make sense in a 64 bits platform, were ssize_t would have 64 
bit dimension, so (ssize_t)(1u<<31) would be positive in that system.
You could say that someone could issue a read() for (1<<63) bytes in a 
64 bits system, but this is even more absurd...




More information about the ffmpeg-devel mailing list