[PATCH] cygwin_rexec() returns pointer to deallocated memory
Mon May 26 21:46:00 GMT 2014
On Mon, May 26, 2014 at 05:40:49PM -0400, Christopher Faylor wrote:
>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
>>>> 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:
>>> 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.
Btw, the latest version of freebsd can't have this particular problem
since ahostbuf is now gone. We probably should pull in the latest version
into Cygwin's tree.
More information about the Cygwin-patches