Re: Compile time string literal substitution to external data file
From: Pieter (msnews_at_insanegenius.com)
Date: 05/22/04
- Next message: Peter Hall: "Re: Lost Header Files"
- Previous message: Stephen Howe: "Re: Bug in 7.1 - does not default initalise member POD arrays in classes when specified in initialisation list"
- In reply to: muchan: "Re: Compile time string literal substitution to external data file"
- Next in thread: muchan: "Re: Compile time string literal substitution to external data file"
- Reply: muchan: "Re: Compile time string literal substitution to external data file"
- Messages sorted by: [ date ] [ thread ]
Date: Sat, 22 May 2004 19:08:57 GMT
Muchan
"Maybe I missed your point. Just hope it helps."
Thank you for the input, but you are missing the point, I want debug output
capabilities in debug build and release build code, but I do not want the
strings in the code.
Pieter
"muchan" <usenet@usenet.usenet> wrote in message
news:5jjrc.3464$37.415044@news.siol.net...
> Pieter wrote:
>
> > Using TRACE type macros to output debug information at runtime is a
powerful
> > debugging technique.
> > This does however have the drawback of leaving the string literals in
the
> > compiled binary, and these string literals may expose sensitive
information
> > e.g. function names etc.
> > Although not a prime motivator, the strings also increase the binary
size
> > without any runtime value.
> >
> > E.g.
> > TRACE("Some sensitive context text e.g. a function name %s\n",
> > szSomeParameter);
> > Where TRACE will resolve to some form of printf like debug output.
> > Will result in the compiled binary containing the following string "Some
> > sensitive context e.g. a function name %s\n".
> > (snip)
>
> >
> > I want to use the compile time macros for file name, line number, and
> > function name in my debug output statement.
> > E.g. __FILE__, __LINE__, and __FUNCTION__:
> > (snip)
>
> Probably I didn't understand your question properly, since I don't see
> too much difficulty for solving?
>
> I'd put a macro and a function like:
>
> // somewhere in .h
> #ifdef DEBUG // some predefined flag of debug build and release build
> #define DEBUGTRACE_ON 1
> #endif
>
> #ifdef DEBUGTRACE_ON
> void DebugTraceFunc(const string& str, char* file, char* line, char*
func);
> #define DebugTrace(str)
(DebugTraceFunc(str,__FILE__,__LINE__,__FUNCTION__))
> #else
> #define DebugTrace(str) {} // do nothing
> #endif
>
> // somewhere in .cpp
> #ifdef DEBUGTRACE_ON
> void DebugTraceFunc(const string& str, char* file, char* line, char*
func)
> {
> string msg("");
> //... format the msg
> Trace(msg.c_str());
> }
> #endif
>
> I didn't test the code, so there may need a modification, but the idea is
> in relase mode (or DEBUG not defined) the macro makes nothing for compiler
to see,
> and in debug mode, it expands to a msg, with info you want to see in
Trace,
> and call to the function which is linked only in debug mode.
>
> A little more work, you can add printf like vaiable numbers parameters,
> or your developer may format the msg just before it like
>
> const string format(char *fmtstring, ...); // defined somewhere else
>
> ... // inside the code
>
> string tracemsg = format("blablabla %s %d", some_str, some_int);
> DebugTrace( tracemsg );
>
> Ha! in this last case blablabla will be in compiled binary...
> Then you sould also put a DebugFormat macro beside DebugTrace macro...
>
> #ifdef DEBUGTRACE_ON
> #define DebugFormat(fmtstr,prm1,prm2,prm3,prm4)
(DebugFormatFunc(fmtstr,prm1,prm2,prm3)) // 4 is 'enough, isn't it?
> #else
> #define DebugFormat(fmtstr,prm1,prm2,prm3,prm4) {} // do nothing
> #endif
>
> // somewhere in .cpp
> #ifdef DEBUGTRACE_ON
> void DebugFormatFunc(char* fmtstring, ...)
> {
> //... format the msg
> }
> #endif
>
> You can integrate them into one macro and one function...
>
> #define DFTrace(fmtstr,prm1,prm2,prm3,prm4)
(DebugFormatTraceFunc(__FILE__,__LINE__,__FUNCTION__,fmtstr,prm1,prm2,prm3))
>
> and user (programer call
>
> DFTrace("blablabla %s %d", "somestring", some_int, 0,0); // 0,0 are
filler,
>
> Release build binary won't contain blablabla, in this case
>
> Maybe I missed your point. Just hope it helps.
>
>
> muchan
>
>
>
>
>
- Next message: Peter Hall: "Re: Lost Header Files"
- Previous message: Stephen Howe: "Re: Bug in 7.1 - does not default initalise member POD arrays in classes when specified in initialisation list"
- In reply to: muchan: "Re: Compile time string literal substitution to external data file"
- Next in thread: muchan: "Re: Compile time string literal substitution to external data file"
- Reply: muchan: "Re: Compile time string literal substitution to external data file"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
