🚀 go-pugleaf

Brian Gregory (bri@primenet.com) wrote:
: I am using Bounds Checker v2.5, and am having a problem finding a
: memory leak it is reporting...

: Example:

: fgets( szBuf, 799, fpIn );

: szBuf is an 800 character buffer (pre-sized array)
: fpIn IS a valid pointer
: no memory is corrupt before the fgets line
: The application is a windows app, written in straight C with a large
: memory model.

: The problem is Boundschecker consistently reports memory leaks for the
: larger buffer size mallocs contained WITHIN the fgets function...

I don't think that the ANSI standard makes any requirement on library functions
that they should not leak memory. (Can anyone construct a requirement from
any execution limit?). So as far as the standard is concerened there is nothing
wrong with your fgets.

: Any help on resolving this recurrent problem, or just an indication
: that this is perhaps an erroneous error reported by Boundschecker
: would be greatly appreciated.

Quality of implementation issues of specific implementations are
outside the scope of this newsgroup. I suggest you take it up with your
supplier or in the newsgroup for your platform.



--
Stephen Baynes                              baynes@ukpsshp1.serigate.philips.nl
Philips Semiconductors Ltd
Southampton                                 My views are my own.
United Kingdom

In article <4ikelh$gji@nnrp1.news.primenet.com> bri@primenet.com (Brian
Gregory) writes:

|> I am using Bounds Checker v2.5, and am having a problem finding a
|> memory leak it is reporting...

|> Example:

|> fgets( szBuf, 799, fpIn );

|> szBuf is an 800 character buffer (pre-sized array)
|> fpIn IS a valid pointer
|> no memory is corrupt before the fgets line
|> The application is a windows app, written in straight C with a large
|> memory model.

|> The problem is Boundschecker consistently reports memory leaks for the
|> larger buffer size mallocs contained WITHIN the fgets function...

Is fpIn ever closed?  (If it is stdin, it normally won't be.)  Most
implementations of stdio will allocate a large buffer (for buffering
purposes) on the first IO to the file, and free it when the file is
closed.  If the file is never closed...

All of the memory checkers I'm familiar with (Purify and my own) have
the possibility to state that certain `leaks' are normal, and shouldn't
be mentioned.
-- 
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité dans une region francophone

In article <4ikelh$gji@nnrp1.news.primenet.com> bri@primenet.com (Brian
Gregory) writes:

|> I am using Bounds Checker v2.5, and am having a problem finding a
|> memory leak it is reporting...

|> Example:

|> fgets( szBuf, 799, fpIn );

|> szBuf is an 800 character buffer (pre-sized array)
|> fpIn IS a valid pointer
|> no memory is corrupt before the fgets line
|> The application is a windows app, written in straight C with a large
|> memory model.

|> The problem is Boundschecker consistently reports memory leaks for the
|> larger buffer size mallocs contained WITHIN the fgets function...

Is fpIn ever closed?  (If it is stdin, it normally won't be.)  Most
implementations of stdio will allocate a large buffer (for buffering
purposes) on the first IO to the file, and free it when the file is
closed.  If the file is never closed...

All of the memory checkers I'm familiar with (Purify and my own) have
the possibility to state that certain `leaks' are normal, and shouldn't
be reported.
-- 
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, études et réalisations en logiciel orienté objet --
                -- A la recherche d'une activité dans une region francophone