On 01/16/2012 01:19 PM, Luiz Capitulino wrote: >> memset(), strlen, strcpy, and friends in <string.h> are all in the class >> of functions that I think are unintentional omissions from the list of >> async-signal-safe functions (they don't read/modify anything but the >> pointers passed in, so the _only_ reason I can think of why they _might_ >> have been omitted from the list is that there might be some machine >> state that could be observably different if you were interrupted in the >> middle of one of these operations, such as a processor flag bit when >> using a rep prefix on x86 controlling which direction to move, but no >> one has ever pointed me to a definitive answer to why they were omitted). > > If this is right we shouldn't be using them then...
The _nice_ thing is that the functions in <string.h> are trivially replaceable by naive variants that _are_ async-signal-safe, since the algorithms behind them are so trivial. It's just that it's annoying to have to tell users that they have to write non-optimized code when doing string ops in a signal handler or after a fork (C code tends to not be as nice as the hand-tuned assembly in glibc for all these low-level functions), for what so far appears to be a theoretical rather than a confirmed restriction on why the standard does not require async-safety. I guess it's time for me to follow through with my threat to file a bug against the POSIX folks to get the string functions added to the list of async-signal-safe, and/or give me stronger justification why they are not already there. -- Eric Blake ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
