[ECOS] Bug in getifaddrs() - allocation of buffer

[Jay Foster]

Attached is a patch to tidy this up.

Jay


-----Original Message-----
From: Gary Thomas [mailto:gary@mlbassoc.com]
Sent: Tuesday, September 16, 2003 9:56 AM
To: Andrew Lunn
Cc: Jay Foster; 'ecos-discuss@sources.redhat.com'
Subject: Re: [ECOS] Bug in getifaddrs() - allocation of buffer


On Tue, 2003-09-16 at 10:37, Andrew Lunn wrote:
> On Tue, Sep 16, 2003 at 08:18:11AM -0700, Jay Foster wrote:
> > The function getifaddrs() in file
packages/net/common/current/src/ifaddrs.c
> > has a couple of bugs in it.
> > 
> > On lines 151 and 157, it calls "free(buf)", but "buf" is a local buffer
> > allocated on the stack.  These should either be removed, or change the 
> > allocation of "buf" to be malloced.  These free() calls seem to indicate
> > that at one time, the "buf" buffer was malloced, which makes sense,
since
> > it is a 1K byte buffer.  This seems a bit large for an auto stack
variable.
> 
> I agree, it should be malloc'd. Its been broken since at least
> 20-May-02!
> 

Actually, it's been broken (in this respect) forever :-(  This is how 
the code looked when originally imported.

> > 
> > On lines 172 through 177 (CYGPKG_NET_INET6), it returns from the
function
> > (error case), but does not free the malloced buffer "data".  Need to add
> > a call to "free(data);" here.  Also, if the "buf" buffer allocation is 
> > changed to be malloced, instead of on the stack, then add a "free(buf);"
> > here too.
> 
> Agreed.

Yes, a little looking at this file and how those pointers [objects] are
allocated and freed would be a good idea.

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss

-------------- next part --------------
A non-text attachment was scrubbed...
Name: ifaddrs.pat
Type: application/octet-stream
Size: 2965 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/ecos-patches/attachments/20030916/e0d30267/attachment.obj>