[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 01:24 PM, M?ns Rullg?rd wrote:
>> jose.goncalves at inov.pt writes:
>>
>>> Hum... I tend to disagree. The definition also says that OK is 0 or a
>>> positive value. So it's better to assume that values not explicitly
>>> indicated (all negative, except -1) are an error. But, this is a minor
>>> thing, the important is to add the missing functionality to
>>> ffmpeg... here goes the corrected patch.
>>>
>> Actually, in this particular case, the ioctl() return value is
>> expected to be zero, so treating any non-zero value as an error is
>> probably the best course of action.  In general, the meaning of the
>> return value is defined by specific request.  The only value reserved
>> as an error code is -1, all others can be valid return values from the
>> requested operation.
>>
>
> 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.

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