This is the mail archive of the
cygwin-patches
mailing list for the Cygwin project.
Re: [PATCH] cygwin_rexec() returns pointer to deallocated memory
- From: Christopher Faylor <cgf-use-the-mailinglist-please at cygwin dot com>
- To: cygwin-patches at cygwin dot com
- Date: Mon, 26 May 2014 17:46:10 -0400
- Subject: Re: [PATCH] cygwin_rexec() returns pointer to deallocated memory
- Authentication-results: sourceware.org; auth=none
- References: <53811668 dot 5010208 at tiscali dot co dot uk> <5382E760 dot 7 at lysator dot liu dot se> <538312E4 dot 1040201 at tiscali dot co dot uk> <5383434B dot 8070508 at lysator dot liu dot se> <53835D4E dot 9040603 at tiscali dot co dot uk> <20140526163505 dot GA7018 at ednor dot casa dot cgf dot cx> <5383A667 dot 9070407 at lysator dot liu dot se> <20140526214049 dot GB4754 at ednor dot casa dot cgf dot cx>
- Reply-to: cygwin-patches at cygwin dot com
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
>>>> 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.
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.
cgf