X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f
X-Recipient: djgpp-workers AT delorie DOT com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        bh=jxLocEtVI6pmzq6gJWJcXiuOgFVuIJrC4ka04xtgs9Q=;
        b=NSREETYJBQaGpMT1pC09M01w98B9tWmp+CFL2drOcyg9uIEKwImHqim1iOt/p3nkt4
         F484or3OCoQgwVH+cyIyZ8RsZ8RC0kYuWI/ooL8o/Gv4COrRLXccedcJ8tvNPuGQGmCY
         vbHHbCOyb328YcuwKd3WeXUCIyIcW7Pzr3hWHM5QClUVegEORJWrgPJ8HRnP/B303vAO
         vbDQj7wsx3FJPw7Peg1MqfOZPQBIdQa5zti/axFDe+Ox/SBrDomM7WpC9kTzpgo3hUIv
         XPz7CpclR/fBcLO42SFelz7eiUc5tEz1aPlca8BdaM3X+TcSoK2sFhJ11gOLKymM/zse
         4imQ==
MIME-Version: 1.0
X-Received: by 10.182.49.166 with SMTP id v6mr26814183obn.13.1387989384621;
 Wed, 25 Dec 2013 08:36:24 -0800 (PST)
In-Reply-To: <52ADF9DA.9060206@iki.fi>
References: <52AD9B08 DOT 1040501 AT iki DOT fi>
	<52ADBDCB DOT 2020203 AT gmx DOT de>
	<52ADCFEC DOT 8000108 AT iki DOT fi>
	<83y53mdq20 DOT fsf AT gnu DOT org>
	<52ADF9DA DOT 9060206 AT iki DOT fi>
Date: Wed, 25 Dec 2013 10:36:24 -0600
Message-ID: <CAA-ihx_xKUFO6OTQO7nK-xfEDtfAeQyV5tH7-WF5uiAMqX5YnA@mail.gmail.com>
Subject: Re: Attempts to build GCC under DOSEMU
From: Rugxulo <rugxulo AT gmail DOT com>
To: djgpp-workers AT delorie DOT com
Content-Type: multipart/alternative; boundary=047d7b5d2ea438f43604ee5e76f4
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

--047d7b5d2ea438f43604ee5e76f4
Content-Type: text/plain; charset=ISO-8859-1

Hi,

On Dec 15, 2013 12:50 PM, "Andris Pavenis" <andris DOT pavenis AT iki DOT fi> wrote:
>
> On 12/15/2013 06:41 PM, Eli Zaretskii wrote:
>>
>> IOW, the null device (and maybe other character devices
>> as well) is broken in FreeDOS-1.1.
>
> It seems so.

I realize that this is considered a deviation from "standard" MS-DOS, but I
can't help but feel it's very unintuitive. Reading from NUL is a horrible
kludge, at best.

Anyways, I did contact two FreeDOS kernel developers back when this was
first mentioned here (two weeks ago). Here's what Jeremy Davis just emailed
me and Eric:

> I believe the issue is in the cooked_read function in chario.c
> CharIO() returns 256 when no bytes are read, ie NUL device returns
immediately with no data (instead of possible data value 0)
> however, along the way there are a few char instead of int causing the
value returned/read to be truncated from 256 to 0
> read_char_sft_dev -> unsigned char c should be unsigned c and the return
value should be int instead of unsigned char.
>
> I have done minimal testing, but these two changes to read_char_sft_dev
seems to fix the nread sample and definitely fixes a bug.
>
> I will try to submit a proper patch to the list and update my kernel
build sometime this week.

So there is hope for a fix.

--047d7b5d2ea438f43604ee5e76f4
Content-Type: text/html; charset=ISO-8859-1

<p>Hi,</p>
<p>On Dec 15, 2013 12:50 PM, &quot;Andris Pavenis&quot; &lt;<a href="mailto:andris DOT pavenis AT iki DOT fi">andris DOT pavenis AT iki DOT fi</a>&gt; wrote:<br>
&gt;<br>
&gt; On 12/15/2013 06:41 PM, Eli Zaretskii wrote:<br>
&gt;&gt;<br>
&gt;&gt; IOW, the null device (and maybe other character devices<br>
&gt;&gt; as well) is broken in FreeDOS-1.1.<br>
&gt;<br>
&gt; It seems so.</p>
<p>I realize that this is considered a deviation from &quot;standard&quot; MS-DOS, but I can&#39;t help but feel it&#39;s very unintuitive. Reading from NUL is a horrible kludge, at best.</p>
<p>Anyways, I did contact two FreeDOS kernel developers back when this was first mentioned here (two weeks ago). Here&#39;s what Jeremy Davis just emailed me and Eric:</p>
<p>&gt; I believe the issue is in the cooked_read function in chario.c<br>
&gt; CharIO() returns 256 when no bytes are read, ie NUL device returns immediately with no data (instead of possible data value 0)<br>
&gt; however, along the way there are a few char instead of int causing the value returned/read to be truncated from 256 to 0<br>
&gt; read_char_sft_dev -&gt; unsigned char c should be unsigned c and the return value should be int instead of unsigned char.<br>
&gt;<br>
&gt; I have done minimal testing, but these two changes to read_char_sft_dev seems to fix the nread sample and definitely fixes a bug.<br>
&gt;<br>
&gt; I will try to submit a proper patch to the list and update my kernel build sometime this week.</p>
<p>So there is hope for a fix.</p>

--047d7b5d2ea438f43604ee5e76f4--