fix off-by-one in dup2
Christopher Faylor
cgf-use-the-mailinglist-please@cygwin.com
Wed Dec 4 17:51:00 GMT 2013
On Wed, Dec 04, 2013 at 06:23:24PM +0100, Corinna Vinschen wrote:
>On Dec 4 12:00, Christopher Faylor wrote:
>> On Wed, Dec 04, 2013 at 01:04:08PM +0100, Corinna Vinschen wrote:
>> >On Dec 4 12:36, Corinna Vinschen wrote:
>> >> On Dec 4 10:32, Corinna Vinschen wrote:
>> >> > Hi guys,
>> >> > [...etc...]
>> >> > The problem is still present in the current sources.
>> >> > [...]
>> >
>> >Ouch, ouch, ouch! I tested the wrong DLL. Actually current CVS fixes
>> >this problem. Duh. Sorry for the confusion.
>> >
>> >One question, though. Assuming start is == size, then the current code
>> >in CVS extends the fd table by only 1. If that happens often, the
>> >current code would have to call ccalloc/memcpy/cfree a lot. Wouldn't
>> >it in fact be better to extend always by at least NOFILE_INCR, and to
>> >extend by (1 + start - size) only if start is > size + NOFILE_INCR?
>> >Something like
>> >
>> > size_t extendby = (start >= size + NOFILE_INCR) ? 1 + start - size : NOFILE_INCR;
>> >
>> >?
>> >
>> >Sorry again. Fortunately it's my WJM week...
>>
>> I don't think it is a common occurrence for start >= size. It is
>> usually done when something like bash dup2's stdin/stdout/stderr to a
>> high fd. Howeer, I'll check in something which guarantees that there is
>> always a NOFILE_INCR entries free after start.
>
>That might be helpful. Tcsh, for instance, always dup's it's std
>descriptors to the new fds 15-19. If it does so in this order, it would
>have to call extend 5 times.
dtable.h:#define NOFILE_INCR 32
It shouldn't extend in that scenario. The table starts with 32
elements.
cgf
More information about the Cygwin-patches
mailing list