Recent Features
| |||||||||||||
Glibc change exposing bugsGlibc change exposing bugsPosted Nov 13, 2010 3:02 UTC (Sat) by cmccabe (guest, #60281)In reply to: Glibc change exposing bugs by dafid_b Parent article: Glibc change exposing bugs
> Is syslog() safe to call at this point?
> It generates formatted output, which seems like it could itself call > memcpy() or do other stuff in te library that the app did not allow for in > its plan when it called memcpy
You raise a good issue. glibc's version of syslog is known to call malloc sometimes, which means that you shouldn't use it from within a signal handler. Surprisingly, memcpy isn't on the official list of "async-signal safe" functions, so you could argue that such an implementation would be POSIX conforming :)
But seriously. I think the best thing to do is probably implement your own version of syslog with no memory allocations or calls to memcpy. It's pretty easy to do in a few hundred lines. I had to do it before when writing a good signal handler.
C.
(Log in to post comments)
|
|||||||||||||