On Mon, May 26, 2014 at 10:39:03PM +0200, Peter Rosin wrote: >On 2014-05-26 18:35, Christopher Faylor wrote: >> On Mon, May 26, 2014 at 04:27:10PM +0100, David Stacey wrote: >>> On 26/05/14 14:36, Peter Rosin wrote: >>>> I believe the comment refers to if "static" is the right answer to the >>>> problem. Is there a need to handle concurrent calls? >>> >>> I can't really comment on that. As the code stands, neither of the two >>> functions that we are discussing are reentrant. As long as the author >>> and the user(s) of the routines are both aware of that then it isn't a >>> problem. >>> >>> I was just trying to fix a coding error that was picked up by Coverity >>> Scan; it wasn't my intention to question the design. >> >> But that is the usual problem with Coverity. Making the simple, obvious >> fix to correct a Coverity warning isn't necessarily the right way to >> deal with the issue. >> >> In this case, the linux man page says: >> >> ATTRIBUTES >> Multithreading (see pthreads(7)) >> The rexec() and rexec_af() functions are not thread-safe. >> >> so static is appropriate. > >"Not thread-safe" doesn't automatically mean that a following call may mess >with what was returned from a prior call (by the same thread). But since >it (IMHO) is a poor interface with no description of how to free any >possibly allocated memory, I agree that static is the only viable option.
The question was about reentrancy. AFAIK, "reentrant" doesn't mean that the buffer passed back from a call can't be subsequently modified by the thread. I'm not aware of any interface which enforces that behavior. cgf
