[FFmpeg-devel] Unix "fileno" libavformat module

[Benoit Fouet]

mark cox wrote:
> On 11/07/07, M?ns Rullg?rd <mans at mansr.com> wrote:
>   
>> William Ahern <william at 25thandClement.com> writes:
>>
>>     
>>>>> +        (void)memcpy(buf, s->rbuf.r.pos, size);
>>>>>           
>>>> why this cast ?
>>>>         
>>> Its not an uncommon style to "cast away" a return value for the purposes
>>>       
>> of
>>     
>>> inline documentation. The intent is to say, "I am willfully ignoring the
>>> return value". The sense becomes clearer for things like close(), and,
>>> especially, snprintf(). WIN32 snprintf() returns -1 on overflow, and
>>>       
>> notably
>>     
>>> does not guarantee null-termination for this condition (effectively the
>>> complete opposite of C99 snprintf()). I've noticed this in some of the
>>> ffmpeg code. A (void) cast in such a situation would (or should) serve
>>>       
>> to
>>     
>>> document that the author understood the behavior and implications.
>>>       
>> All I've ever seen such casts indicate is the author using compiler
>> (or worse, lint tool) giving warnings unless those casts were added.
>> If done often enough, it could well become an unconscious habit.
>>
>> In the memcpy() case, I can't recall having ever seen the return value
>> being used.
>>     
>
>
> I also use (void) in this way as a documentation tool. It is useful, but in
> this case i think for common fn's like malloc and memcpy it is not useful.
>
>   

i think people not checking the malloc() return value are doing
something wrong :)

-- 
Ben
Purple Labs S.A.
www.purplelabs.com