Re: bug in openlog()

[Christopher Allen Wing]

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