>> I believe we should avoid the word "reentrant",

Well, unless we really mean it.

>> [...] because the word "reentrant" may mean async-signal-safe in
>> some technical context.

Not quite; it's stronger than (my understanding of) async-signal-safe.
An async-signal-safe function may be called from a signal handler
without taking any particular precautions to make sure that the signal
can be delivered only at particular times - right?

A reentrant routine may be called at any point during its own
execution, for example from a signal handler (or hardware interrupt, in
environments where that makes sense), to unlimited depth.

>> For example, Wikipedia (http://en.wikipedia.org/wiki/Reentrant) says:
>> 	To be reentrant, a function must hold no static data, must not
>> 	return a pointer to static data, must work only on the data
>> 	provided to it by the caller, and must not call non-reentrant
>> 	functions.

I think the Wikipedia is wrong.  There is nothing wrong with returning
pointers to static data in some cases.  For example,

const char *k_str(int code)
{
	switch (code) {
		case K_FOO: return("foo"); break;
		case K_BAR: return("bar"); break;
		case K_BAZ: return("baz"); break;
		default: return("?""?"); break;
	}
}

is a totally reentrant function, even though it *always* returns a
pointer to static data.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B