X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
From: "Rod Pemberton" <do_not_have AT nohavenot DOT cmm>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: DJGPP Setup?
Date: Wed, 25 Mar 2009 03:38:58 -0400
Organization: Aioe.org NNTP Server
Lines: 81
Message-ID: <gqcmsq$n40$1@aioe.org>
References: <0KGZ00GQ8UBIYMM0 AT mta4 DOT srv DOT hcvlny DOT cv DOT net> <gqadn4$qc1$1 AT aioe DOT org> <uab7aoowh DOT fsf AT gnu DOT org>
NNTP-Posting-Host: pldq+kT97bAAp/ObDwnZyQ.user.aioe.org
X-Complaints-To: abuse AT aioe DOT org
NNTP-Posting-Date: Wed, 25 Mar 2009 07:35:54 +0000 (UTC)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1933
X-Notice: Filtered by postfilter v. 0.7.7
X-Newsreader: Microsoft Outlook Express 6.00.2800.1933
Cancel-Lock: sha1:tP3Y32uhxED+qCz4ylsCzr8YEB0=
X-Priority: 3
X-MSMail-Priority: Normal
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

"Eli Zaretskii" <eliz AT gnu DOT org> wrote in message
news:uab7aoowh DOT fsf AT gnu DOT org...
> > Perhaps, DOS is automatically closing your extra files or DJGPP is
reusing
> > the file handles... (?)
>
> I don't believe any of this is, or could be, happening.

Does DJGPP also boost the file handles and copy all of them to child
processes?...  Or, does it just use the 20 passed by the parent?  Doesn't
DJGPP close handles 18 and 19 in child processes as stated for fcntl()?
What if he was using FCB's?  Doesn't DOS close FCB file handles that exceed
a limit automatically?  What if he was using freopen() on stderr, stdio, or
stdin, or was using tmpfile() and found a bug? What about improperly linked
extern FILE *'s?

> void
> __file_handle_set(int fd, int mode)
> {
>   __dpmi_regs r;
>
>   if (dosio_bss_count != __bss_count)
>   {
>     dosio_bss_count = __bss_count;
>     count = 20;
>     __file_handle_modes = init_file_handle_modes;
>   }
>
>   /* Check for bogus values */
>   if (fd < 0)
>     return;
>
>   /* 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...?

>    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()?

>    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?  This
screams "off by one error" even if I don't see one in this case...  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.  Of course,
DJGPP couldn't possibly use calloc() which does malloc/memset and checks the
NULL too, since that would destroy the visually beautiful code of malloc()
and memset()...

>    /* 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.

>  /* Fill in the value */
>  __file_handle_modes[fd] = mode;
>}


Rod Pemberton