elog with automatic file, line, and function

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, 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__);

--
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.

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.

AIX xlc has __FUNCTION__, but unfortunately no __func__ or __PRETTY...
It outputs the full demagled funcname with __FUNCTION__ (like __PRETTY...).

I do not think it would be appropriate to send file, line and func infos to the
client though.

Andreas

* 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

Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at> writes:

I do not think it would be appropriate to send file, line and func
infos to the client though.

We still need to work out the details, but my first thought would be to
make this conditional on the value of some SET variable. Also, probably
the info should always be recorded in the postmaster log.

regards, tom lane

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