X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Recipient: djgpp AT delorie DOT com Date: Wed, 25 Mar 2009 18:24:51 +0200 From: Eli Zaretskii Subject: Re: DJGPP Setup? In-reply-to: X-012-Sender: halo1 AT inter DOT net DOT il To: djgpp AT delorie DOT com Message-id: References: <0KGZ00GQ8UBIYMM0 AT mta4 DOT srv DOT hcvlny DOT cv DOT net> Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > From: "Rod Pemberton" > 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.