errmsg() clobbers errno
Hi All
While debugging an extension I discovered that the errmsg()
function zeros out errno.
This is annoying because if the process of assembling a meaningful
error message happens to call errmsg() before calling strerror()
we lose the strerror information. This is exactly the time when we
want to preserve any available error state.
I am attaching a patch to preserve errno across errmsg() calls.
Does this seem like a good idea?
Best, John
Attachments:
errmsg-errno-v1.patchapplication/octet-stream; name=errmsg-errno-v1.patchDownload
diff --git a/src/backend/utils/error/elog.c b/src/backend/utils/error/elog.c
index dfd102a..f27ab56 100644
--- a/src/backend/utils/error/elog.c
+++ b/src/backend/utils/error/elog.c
@@ -791,6 +791,7 @@ int
errmsg(const char *fmt,...)
{
ErrorData *edata = &errordata[errordata_stack_depth];
+ int saved_errno = errno; /* Not clobber errno. */
MemoryContext oldcontext;
recursion_depth++;
@@ -801,6 +802,7 @@ errmsg(const char *fmt,...)
MemoryContextSwitchTo(oldcontext);
recursion_depth--;
+ errno = saved_errno;
return 0; /* return value does not matter */
}
John Gorman <johngorman2@gmail.com> writes:
While debugging an extension I discovered that the errmsg()
function zeros out errno.
So might a lot of other functions used in an ereport's arguments.
This is annoying because if the process of assembling a meaningful
error message happens to call errmsg() before calling strerror()
we lose the strerror information.
This is why you should use %m and not strerror(errno). The infrastructure
for %m is set up so that errno is captured before evaluating any of the
ereport's arguments.
I am attaching a patch to preserve errno across errmsg() calls.
This is pretty useless, unfortunately, because there are just too
many ways to bite yourself on the rear if you reference errno inside
the arguments of an ereport (or any other complicated nest of function
calls).
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers