|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 5/5] mkelf32: Close those file descriptors in the error paths.
>>> On 18.02.16 at 22:12, <konrad.wilk@xxxxxxxxxx> wrote:
> On Thu, Feb 18, 2016 at 09:45:30AM -0700, Jan Beulich wrote:
>> >>> On 18.02.16 at 17:39, <Ian.Jackson@xxxxxxxxxxxxx> wrote:
>> > Jan Beulich writes ("Re: [PATCH v3 5/5] mkelf32: Close those file
> descriptors
>> > in the error paths."):
>> >> On 12.02.16 at 04:08, <konrad.wilk@xxxxxxxxxx> wrote:
>> >> > While we are operating here we may as well fix some of the
>> >> > file descriptor leaks.
>> >>
>> >> I'm not convinced. The added goto-s make the code uglier to read,
>> >> and this being a standalone utility there's not really any leak here.
>> >
>> > I don't buy this `uglier to read'. What `return 1' does is make me
>> > think `is some resource being leaked' and `do I need to audit this
>> > thing'.
>>
>> Certainly a matter of taste to some degree - goto-s are always
>> ugly to read to my eyes. Irrespective of this I don't buy the leak
>> aspect for a non-library like, short running build utility. The close()
>> calls are just more code, with absolutely no added benefit to the
>> system the code runs on.
>
> <chuckles>
>
> If I turned them in:
>
> if (..blah..)
> {
> close(infd);
> return -1;
> }
>
> would that satisfy you?
Since presumably this would be on a number of error paths, I'm
afraid ...
> (Irrespective of the 'no added benefit to the system the code runs
> on.').
... this aspect would still be an relevant one.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |