[libvirt] [PATCH] openvzGetVEID: don't leak (memory + file descriptor)

2010-02-25 Thread Jim Meyering
Coverity spotted the leaks. Here's a proposed fix. I didn't bother with a separate diagnostic for the unlikely event that we read a negative number from the pipe. Seems far-fetched enough not to bother, but it's easy to add, if anyone cares. >From f3439c7eae46681eacf5b469a6f0e22cb8fec1b4 Mon Sep

Re: [libvirt] [PATCH] openvzGetVEID: don't leak (memory + file descriptor)

2010-02-25 Thread Eric Blake
According to Jim Meyering on 2/25/2010 12:01 PM: >> You're still keeping with fscanf. > > Yes. There are plenty of bigger fish to fry, for now ;-) > As it is, this is more of a rearrangement than I generally > prefer "just to fix a leak". Indeed, I have no problem with checking in your patch as-

Re: [libvirt] [PATCH] openvzGetVEID: don't leak (memory + file descriptor)

2010-02-25 Thread Jim Meyering
Eric Blake wrote: > According to Jim Meyering on 2/25/2010 11:30 AM: > > ACK on plugging the leak. However,... Thanks for the review. >> @@ -979,18 +980,12 @@ int openvzGetVEID(const char *name) { >> return -1; >> } >> >> -if (fscanf(fp, "%d\n", &veid ) != 1) { >> +ok = fsc

Re: [libvirt] [PATCH] openvzGetVEID: don't leak (memory + file descriptor)

2010-02-25 Thread Eric Blake
According to Jim Meyering on 2/25/2010 11:30 AM: ACK on plugging the leak. However,... > @@ -979,18 +980,12 @@ int openvzGetVEID(const char *name) { > return -1; > } > > -if (fscanf(fp, "%d\n", &veid ) != 1) { > +ok = fscanf(fp, "%d\n", &veid ) == 1; You're still keeping