[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