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

[Måns Rullgård]

Jos? Miguel Gon?alves <jose.goncalves at inov.pt> writes:

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

Why not?  2GB isn't much of a file size nowadays, nor is the same
amount of RAM.

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

Not true, and that is my point.  A negative return value other than -1
from read() does not indicate error.  Cast it to size_t, and you have
the number of bytes read (if the system supports it).

> You could say that someone could issue a read() for (1<<63) bytes in a
> 64 bits system, but this is even more absurd...

That would be somewhat absurd, yes.

-- 
M?ns Rullg?rd
mans at mansr.com