[CinCV TNG] [PATCH] close_all should consistently return 0, not 1.

Nicola Ferralis feranick at hotmail.com
Wed Apr 8 14:30:33 CEST 2015


Hi Einar,

Thanks. In addition to this patch, the only other recent one is "Fix copy and paste error in cwindowgui.C". I am not aware of any other outstanding one.

I also submitted, not as an official patch just yet but only as a " release candidate" of the GreyCstoration plugin for people to test. It works very well on my tests, but given its complexity a little more user testing would help before I submit it as an official patch.

I am still working on the motionblur plugin (to prevent it from crashing). While I found where the problem is (see my previous note), I cannot find why that is crushing cinelerra...

Thanks,
Nicola

On Apr 8, 2015 1:58 AM, Einar R√ľnkaru <einarry at smail.ee> wrote:
Hi.

On Tue, Apr 7, 2015 at 11:28 PM, Nicola Ferralis <feranick at hotmail.com> wrote:
> It's a matter of consistency across similar calls. My bad that it should
> have been the same since the beginning.
>
> Nicola
>
>
> On 4/7/15 4:25 PM, Johannes Sixt wrote:
>>
>> Am 07.04.2015 um 22:00 schrieb Nicola Ferralis:
>>>
>>> Hi, I was wondering if there are any comments on this patch.
>>>
>>> Thanks.
>>> Nicola
>>>
>>> On 3/31/15 4:52 PM, Nicola Ferralis wrote:
>>>>
>>>> The non-zero return value of close_all in audioesound and audioalsa
>>>> is not consistent with similar calls in other audio*.C and video*.C
>>>> files. close_all is called upon by parent functions that then return
>>>> 0 themselves. If close_all returns non-zero, there may be issues
>>>> where the event is consumed within close_all. This patch sets the
>>>> returns to zero.
>>>>
>>>> This was a mistake I introduced in commit b7e5b1ae3a, based on wrong
>>>> consideration of the role of close_all as an event.
>>
>>
>> I don't see where the return value of close_all() is relevant. Where
>> exactly is it inspected?
>>
>> At this point, it would be much better to convert all incarnations of
>> the function to void rather than fixing a small consistency error that
>> has no consequence.

The problem of Cinelerra is that it has not error paths. The most it
does - prints error message and continues like there is no error.
These paths should be created.

System close function returns zero if everything is ok and not zero
when an error occures. IMHO we must follow the same rule especially
with hardware devices. Today there is no error detection - it is the
task of future to write it. Returning result is a part of error
detection path and should be kept.

The patch is fine.

Nicola, you have sent more than one good patches that are not dropped
or applied. Can you make some inventory and apply (or drop) them?

Einar
_______________________________________________
Cinelerra mailing list
Cinelerra at lists.cinelerra-cv.org
http://lists.cinelerra-cv.org/cgi-bin/mailman/listinfo/cinelerra
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cinelerra-cv.org/pipermail/cinelerra/attachments/20150408/437111ca/attachment.html>


More information about the Cinelerra mailing list