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
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

--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--

- Raw text -