Thread: elog with automatic file, line, and function
It has been brought up that elog should be able to automatically fill in the file, line, and perhaps the function name where it's called, to avoid having to prefix each message with the function name by hand, which is quite ugly. This is doable, but it requires a C preprocessor that can handle varargs macros. Since this is required by C99 and has been available in GCC for a while, it *might* be okay to rely on this. Additionally, C99 (and GCC for a while) would allow filling in the function name automatically. Since these would be mostly developer features, how do people feel about relying on modern tools for implementing these? The bottom line seems to be that without these tools it would simply not be possible. -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
> It has been brought up that elog should be able to automatically fill in
> the file, line, and perhaps the function name where it's called, to avoid
> having to prefix each message with the function name by hand, which is
> quite ugly.
> Since these would be mostly developer features, how do people feel about
> relying on modern tools for implementing these?
Not happy. A primary reason for wanting the exact location is to make
bug reports more specific. If Joe User's copy of Postgres doesn't
report error location then it doesn't help me much that my copy does
(if I could reproduce the reported failure, then gdb will tell me where
the elog call is...). In particular, we *cannot* remove the habit of
mentioning the reporting routine name in the message text unless there
is an adequate substitute in all builds.
> The bottom line seems to be that without these tools it would simply
> not be possible.
Sure it is, it just requires a marginal increase in ugliness, namely
double parentheses:
ELOG((level, format, arg1, arg2, ...))
which might work like
#define ELOG(ARGS) (elog_setloc(__FILE__, __LINE__), elog ARGS)
> Additionally, C99 (and GCC for a while) would allow filling in the
> function name automatically.
We could probably treat the function name as something that's optionally
added to the file/line error report info if the compiler supports it.
BTW, how does that work exactly? I assume it can't be a macro ...
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > > Additionally, C99 (and GCC for a while) would allow filling in the > > function name automatically. > > We could probably treat the function name as something that's optionally > added to the file/line error report info if the compiler supports it. > > BTW, how does that work exactly? I assume it can't be a macro ... It's a macro just like __FILE__ and __LINE__ are macros. gcc has supported __FUNCTION__ and __PRETTY_FUNCTION__ for a long time (the latter is the demangled version of the function name when using C++). Ian
Ian Lance Taylor <ian@airs.com> writes:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
>> BTW, how does that work exactly? I assume it can't be a macro ...
> It's a macro just like __FILE__ and __LINE__ are macros.
> gcc has supported __FUNCTION__ and __PRETTY_FUNCTION__ for a long time
> (the latter is the demangled version of the function name when using
> C++).
Now that I know the name, I can find it in the gcc docs, which clearly
explain that these names are not macros ;-). The preprocessor would
have a tough time making such a substitution.
However, if the C99 spec has such a concept, they didn't use that name
for it ...
regards, tom lane
* Tom Lane <tgl@sss.pgh.pa.us> [010319 18:58]: > Ian Lance Taylor <ian@airs.com> writes: > > Tom Lane <tgl@sss.pgh.pa.us> writes: > >> BTW, how does that work exactly? I assume it can't be a macro ... > > > It's a macro just like __FILE__ and __LINE__ are macros. > > > gcc has supported __FUNCTION__ and __PRETTY_FUNCTION__ for a long time > > (the latter is the demangled version of the function name when using > > C++). > > Now that I know the name, I can find it in the gcc docs, which clearly > explain that these names are not macros ;-). The preprocessor would > have a tough time making such a substitution. > > However, if the C99 spec has such a concept, they didn't use that name > for it ... My C99 compiler (SCO, UDK FS 7.1.1b), defines the following: Predefined names The following identifiers are predefined as object-like macros: __LINE__ The current line number as a decimal constant. __FILE__ A string literal representing the name of the file being compiled. __DATE__ The date of compilation as a string literal in the form ``Mmm dd yyyy.'' __TIME__ The time of compilation, as a string literal in the form ``hh:mm:ss.'' __STDC__ The constant 1 under compilation mode -Xc, otherwise 0. __USLC__ A positive integer constant; its definition signifies a USL C compilation system. Nothing for function that I can find. LER > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Peter Eisentraut wrote:
>
> It has been brought up that elog should be able to automatically fill in
> the file, line, and perhaps the function name where it's called, to avoid
> having to prefix each message with the function name by hand, which is
> quite ugly.
>
> This is doable, but it requires a C preprocessor that can handle varargs
> macros. Since this is required by C99 and has been available in GCC for a
> while, it *might* be okay to rely on this.
>
> Additionally, C99 (and GCC for a while) would allow filling in the
> function name automatically.
>
> Since these would be mostly developer features, how do people feel about
> relying on modern tools for implementing these? The bottom line seems to
> be that without these tools it would simply not be possible.
It is possible, however, the macros require an extra set of parentheses:
void elog_internal(const char* file, unsigned long line, ... );
#define ELOG(args) elog_internal(__FILE__, __LINE__, args)
ELOG(("%s error", string))
For portability to older compilers, you should probably not require C99.
Also, I'm not positive, but I think that varargs are not part of C++
yet.
However, they will likely be added (if not already in draft form).
Neal
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
Larry Rosenman writes:> * Tom Lane <tgl@sss.pgh.pa.us> [010319 18:58]:> > However, if the C99 spec has such a concept,
theydidn't use that name> > for it ...> My C99 compiler (SCO, UDK FS 7.1.1b), defines the following:> Predefined names>
>The following identifiers are predefined as object-like macros: > > > __LINE__> The current line number as a
decimalconstant. > > __FILE__> A string literal representing the name of the file being compiled. > > __DATE__>
Thedate of compilation as a string literal in the form ``Mmm dd> yyyy.'' > > __TIME__> The time of compilation, as
astring literal in the form> ``hh:mm:ss.'' > > __STDC__> The constant 1 under compilation mode -Xc, otherwise 0. >
>__USLC__> A positive integer constant; its definition signifies a USL C> compilation system. > > Nothing for
functionthat I can find.
It is called __func__ in C99 but it is not an object-like macro. The
difference is that it behaves as if it were declared thus.
static const char __func__[] = "function-name";
Those other identifiers can be used in this sort of way.
printf("Error in " __FILE__ " at line " __LINE__ "\n");
But you've got to do something like this for __func__.
printf("Error in %s\n", __func__);
--
Pete Forman -./\.- Disclaimer: This post is originated
WesternGeco -./\.- by myself and does not represent
pete.forman@westerngeco.com -./\.- opinion of Schlumberger, Baker
http://www.crosswinds.net/~petef -./\.- Hughes or their divisions.
* Pete Forman <pete.forman@westerngeco.com> [010320 04:22]:
> Larry Rosenman writes:
> > * Tom Lane <tgl@sss.pgh.pa.us> [010319 18:58]:
> > > However, if the C99 spec has such a concept, they didn't use that name
> > > for it ...
> > My C99 compiler (SCO, UDK FS 7.1.1b), defines the following:
> > Predefined names
> >
> > The following identifiers are predefined as object-like macros:
> >
> >
> > __LINE__
> > The current line number as a decimal constant.
> >
> > __FILE__
> > A string literal representing the name of the file being compiled.
> >
> > __DATE__
> > The date of compilation as a string literal in the form ``Mmm dd
> > yyyy.''
> >
> > __TIME__
> > The time of compilation, as a string literal in the form
> > ``hh:mm:ss.''
> >
> > __STDC__
> > The constant 1 under compilation mode -Xc, otherwise 0.
> >
> > __USLC__
> > A positive integer constant; its definition signifies a USL C
> > compilation system.
> >
> > Nothing for function that I can find.
>
> It is called __func__ in C99 but it is not an object-like macro. The
> difference is that it behaves as if it were declared thus.
>
> static const char __func__[] = "function-name";
>
> Those other identifiers can be used in this sort of way.
>
> printf("Error in " __FILE__ " at line " __LINE__ "\n");
>
> But you've got to do something like this for __func__.
>
> printf("Error in %s\n", __func__);
>
I couldn't find it in the docs, but it is in the compiler.
Wierd.
I'll look more.
LER
> --
> Pete Forman -./\.- Disclaimer: This post is originated
> WesternGeco -./\.- by myself and does not represent
> pete.forman@westerngeco.com -./\.- opinion of Schlumberger, Baker
> http://www.crosswinds.net/~petef -./\.- Hughes or their divisions.
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 972-414-9812 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Tom Lane writes: > Sure it is, it just requires a marginal increase in ugliness, namely > double parentheses: > > ELOG((level, format, arg1, arg2, ...)) > > which might work like > > #define ELOG(ARGS) (elog_setloc(__FILE__, __LINE__), elog ARGS) Would the first function save the data in global variables? -- Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Peter Eisentraut <peter_e@gmx.net> writes:
> Tom Lane writes:
>> #define ELOG(ARGS) (elog_setloc(__FILE__, __LINE__), elog ARGS)
> Would the first function save the data in global variables?
Yes, that's what I was envisioning. Not a super clean solution,
but workable, and better than requiring varargs macros.
regards, tom lane