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

José Miguel Gonçalves jose.goncalves
Mon Sep 13 17:11:46 CEST 2010

On 09/13/2010 03:41 PM, M?ns Rullg?rd wrote:
> 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.

I mostly work in embedded systems were a read above 1MB is already absurd.
But OK, I agree that is nowadays possible in some platforms.

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

Why is it not true?  The POSIX definition for read() says on the return 

"Upon successful completion, these functions shall return a non-negative 
integer indicating the number of bytes actually read."

More information about the ffmpeg-devel mailing list