Date: Sat, 13 May 2000 17:22:08 -0400 (EDT)
Message-Id: <200005132122.RAA16253@indy.delorie.com>
From: Eli Zaretskii <eliz AT delorie DOT com>
To: Andris Pavenis <pavenis AT latnet DOT lv>
CC: djgpp-workers AT delorie DOT com
In-reply-to: <00051313422100.25039@hal> (message from Andris Pavenis on Sat,
	13 May 2000 13:35:51 +0200)
Subject: Re: Patch for dtou.c and utod.c
References:  <00051313422100 DOT 25039 AT hal>
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

> From: Andris Pavenis <pavenis AT latnet DOT lv>
> Date: Sat, 13 May 2000 13:35:51 +0200
>
> I'm including below a patches for src/utils/dtou.c and src/utils/utod.c 
> to make the same sources usable not only on DOS platform as I think it 
> could be usefull to use the same utilities together with DJGPP targetted
> cross-compiler instead of looking for other ones.

Thanks!

I have several comments:

> !   strcpy (tfname, fname);
> !   for (bn=w=tfname; *w; w++) 
> !     if (*w=='/' || *w=='\\') 
> !       bn = w+1;  
> !   if (bn) *bn=0;
> !   strcat (tfname,"utod.tm$");

This fragment from dtou.c doesn't seem to cover the case of "d:foo".
(A similar problem exists in utod.c.)

>     while ((l=read(sf, buf, 16384)) > 0)
> !   { 
> !     for (i=k=0; i<l; i++) 
> !       if (buf[i]!=13)
> !         buf[k++]=buf[i];
> !     l2=write(df, buf, k);
> !     if (l2<0) break;
> !     if (l2!=k) { err=1; break; }
> !   }

If you open the file in binary mode, it would make sense to handle the
case of a lone CR character (without an LF right after it), instead of
removing it, like the library does.  Also, you need to handle the case
of trailing ^Z characters (done by the library in the current
version).

>     while ((l=read(sf, buf, 16384)) > 0)
> !   {
> !     int iscr=0;
> !     for (i=k=0; i<l; i++)
> !     {
> !       if (buf[i]==10 && !iscr) buf2[k++]=13;
> !       iscr=buf[i]==13 ? 1 : 0;
> !       buf2[k++]=buf[i];
> !     }

This doesn't seem to handle the case when the buffer read from the
input file happens to end with a CR, whose LF is in the next
buffer-ful (because the value of iscr is reset after each call to
`read').