Mail Archives: djgpp/2009/03/25/11:24:55
> From: "Rod Pemberton" <do_not_have AT nohavenot DOT cmm>
> Date: Wed, 25 Mar 2009 03:38:58 -0400
>
> Does DJGPP also boost the file handles and copy all of them to child
> processes?...
No, that's impossible: only the 1st 20 handles can be inherited.
These are DOS limitations.
> Doesn't DJGPP close handles 18 and 19 in child processes as stated
> for fcntl()?
Yes, I think it does. But then, not every program invokes child
processes, so this feature is still useful, IMO, even if it's true.
> What if he was using FCB's?
That's why I asked what functions he used to open the files.
> > /* See if we need to expand the tables. Check this BEFORE it might fail,
> > so that when we hit the count'th request, we've already up'd it. */
> > if (fd >= (count-1) && count < 255)
> > {
>
> If "it might fail" on the"count'th request", i.e., 20'th, wouldn't it also
> possibly fail on the count'th-1 request, i.e., 19'th...? count'th-2...?
"might fail" here refers to the potential attempt in the future to
open the 21st file. If the program never does that, that failure will
never happen; thus "might".
> > int oldcount = count;
> > count = 255;
> >
> > __file_handle_modes = (char *)malloc(count * sizeof(*__file_handle_modes));
>
> 1) Should anyone be casting malloc() anymore?
> 2) Check if NULL pointer returned by malloc()?
Patches are welcome.
>
> > memcpy(__file_handle_modes, init_file_handle_modes, sizeof(init_file_handle_modes));
> > memset(__file_handle_modes + oldcount, 0, (count-oldcount)*sizeof(__file_handle_modes[0]));
>
> Wouldn't it be safer to memset() or clear the entire new
> __file_handle_modes[] first, then memcpy() the existing handles?
Why is it safer?
> This
> screams "off by one error" even if I don't see one in this case...
There isn't one.
> It is interesting to note that there is a change of programming
> style in the use of sizeof() on__file_handle_modes in malloc()
> versus memset.
What change of style? I don't see any.
> > /* Tell DOS to allow more */
> > r.h.ah = 0x67;
> > r.x.bx = count;
> > __dpmi_int(0x21, &r);
> > }
> >
>
> And, there is no check of the CF for failure.
And for a good reason: this code is doing the job for the _next_ call
to _open, not for _this_ call. The caller has no idea that the
library is silently preparing for it to open another file. Returning
a failure for a _possible_future_ call would be very confusing indeed,
and what exactly you expect the caller to do with it?
OTOH, if 2167 fails here, the next _open will simply fail with "no
more handles", which correctly explains the reason.
So I see no problem with not checking CF in this particular case.
But again, patches are welcome.
- Raw text -