On 2014-05-26 12:09, David Stacey wrote: > On 26/05/14 08:04, Peter Rosin wrote: >> On 2014-05-25 00:00, David Stacey wrote: >>> In function cygwin_rexec(), a pointer to local buffer 'ahostbuf' is >>> returned through 'ahost'. However, the buffer will have been deallocated at >>> the end of the function, and so the contents of 'ahost' will be undefined. >>> A trivial patch (attached) fixes the problem by making 'ahostbuf' static. >>> This patch fixes Coverity bug ID #60028. >>> Change Log: >>> 2014-05-24 David Stacey<[email protected]> >>> * libc/rexec.cc (cygwin_rexec): >>> Corrected returning a pointer to a buffer that will have gone out >>> of >>> scope. >> I'm comparing with [1] and the same comment is applicable here (reading "it" >> as "static"). >> >> [1]https://cygwin.com/viewvc/src/winsup/cygwin/libc/rcmd.cc?revision=1.8&view=markup#l134 > > The two functions behave in a similar fashion. In both cases, an out > parameter called 'ahost' is assigned to a buffer that is local to the > function. The case of cygwin_rcmd_af() is correct in that the buffer is > created statically (and so the buffer will not be destroyed at the end of the > function). This means that the contents of the buffer will be available to > the calling function. > > However, in the case of cygwin_rexec(), the buffer is not static and is > allocated on the stack. Hence after the function, if the stack were to be > used (e.g. for local variables or function parameters) the contents of the > buffer could easily become corrupted. > > So yes, I would argue that 'static' is appropriate in both cases.
I believe the comment refers to if "static" is the right answer to the problem. Is there a need to handle concurrent calls? Cheers, Peter
