[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bug in openlog()
From: |
Christopher Allen Wing |
Subject: |
Re: bug in openlog() |
Date: |
Fri, 21 Dec 2001 17:10:52 -0500 (EST) |
Ulrich:
Thanks for writing back!
On 20 Dec 2001, Ulrich Drepper wrote:
> Christopher Allen Wing <address@hidden> writes:
>
> > The problem is that if the pointer becomes invalid for some reason, or if
> > the string is overwritten, future syslog output will be corrupted, or the
> > program might crash.
>
> The pointer must not become invalid. Period.
I know. But since this isn't clearly documented, I find it hard to fault
programmers for not obeying this requirement.
I don't think that glibc has done anything wrong here; the original BSD
syslog interface just leaves a lot to be desired.
I took a quick look into glibc, and openlog() is the only interface that I
could find which acts in this way (takes a string pointer and uses it as a
global internal variable). On the other hand, there are several interfaces
that copy strings, for example:
int addseverity(int severity, const char *string)
(strdup()s 'string' into an internal list)
FTS * fts_open(char * const *path_argv, int options,
int (*compar)(const FTSENT **, const FTSENT **))
(strdup()s the strings in 'path_argv' into new FTS
structure, subsequent fts calls use the copies)
void utmpname(const char *file)
void utmpxname (const char *file)
(strdup()s 'file' and uses the copy in an internal
variable)
I guess that my opinion is it wouldn't hurt to change the internal
behavior of syslog() for consistency.
I do see your point, though. If the programmer hands over a text string to
be used in formatted output, he/she should be responsible for keeping
track of it. And it shouldn't be the C library's duty to work around all
problems with other software.
In any case, can we at least update the documentation to spell out this
requirement explicitly, and make a note of the (previously undocumented)
behavior of closelog(), so that future programmers have a greater chance
of avoiding problems in the future?
Here is a proposed patch for the documentation:
http://www.engin.umich.edu/caen/systems/Linux/code/patches/glibc-2.2.4-manual.patch
Thanks,
Chris Wing
address@hidden