[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130409132625.Y9ISO.1530.imail@eastrmwml213>
Date: Tue, 9 Apr 2013 9:26:25 -0400
From: <jfoug@....net>
To: john-dev@...ts.openwall.com
Cc: Frank Dittrich <frank_dittrich@...mail.com>
Subject: Re: New addition to JtR. memdbg, self-validating
memory management functions
---- Frank Dittrich <frank_dittrich@...mail.com> wrote:
>
> Wouldn't it be better to include memdbg.h in a core include file, so
> that you can enable the switch and rely on the fact that you really
> trace all uses of memory functions, and don't have to search for all the
> newly added formats or other functionality which didn't include memdbg.h?
It is not that easy. Here is the problem, declaration vs definition.
putting memdbg.h early on in build of an object file:
compiler reads this line:
#define free(a) MEMDBG_free(a, __FILE__, __LINE__)
then later in the compile, in some other header, the compiler sees:
extern void _cdecl free(void *ptr);
However, the compiler does not see that. The preprocessor will output this line, which the compiler says, "what?!?!?" over:
extern void _cdecl free(void *ptr, "some_file.h", 1234);
So what you end up with is part declaration, and part definition, and the compiler will puke over that. Unfortunately, I have found free(), strdup() and even malloc scattered into many different header files, so getting code that is 100% 'sure' to have included all headers where these could possibly be defined is not easy, for all compilers. If someone can show HOW to do this, then yes, we could put this into some early header(s).
Jim.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
