Subject: putc bug ?
From: [email-masked] (John Gumb)

22 Jun 1998 04:57:34 -0700
Message-ID: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
To: [email-masked]

Hi,

For amusement, I've been trying to port Intel's I960 tools (CTOOLS)
to run under Cygnus on 95/NT. I'm almost there...but an oddity in
putc seems to be causing problems.

It is illustrated by the following which simply writes values
0..255 to a file twice. The problem appears to be when 
putc(0x0a) is invoked. It looks to me like putc in it's
wisdom thinks a <CR> should be inserted before what putc
interprets as <LF>. Clearly, under a windows environment
this might be a reasonable thing to do. However, when putc is
being used to output characters to file of object code,
things get a little confused.....not least me.

Surely it can't be within the ANSI/POSIX rules for putc to be
doing this ?

Interestingly, the above 'problem' happens using Microsoft VC++5.
Wonder if there's a connection....?

I embarked on this exercise to see how robust Cygwin32 was. Thus
far it's done a great job of getting the i960 utils going. To help
me suss out this one I got them going under Linux first. Considering
how much code goes into the i960 tools which has required a minium of
tweaking, Cygwin is pretty impressive stuff.

Comments ?

John
[email-masked]

P.S. I'm running under Beta 19.1
P.P.S. There's a lot to be said for Linux.
--------------------------------------------------------------------
#include <stdio.h>

int main (int argc, char *argv[])
{
  int i;
  FILE *outfile;

  outfile = fopen("d.dat","w");

  for (i=0; (i<512); i++)
  {
	fputc((i & 0xFF), outfile);
  }

  fclose(outfile);

  return 42;
}

Built under NT/Cygnus: note 0d inserted before 0a

bash$ hexdump d.dat
0000000 0100 0302 0504 0706 0908 0a0d 0c0b 0e0d
0000010 100f 1211 1413 1615 1817 1a19 1c1b 1e1d
.....
0000100 00ff 0201 0403 0605 0807 0d09 0b0a 0d0c
0000110 0f0e 1110 1312 1514 1716 1918 1b1a 1d1c
.....
00001f0 efee f1f0 f3f2 f5f4 f7f6 f9f8 fbfa fdfc
0000200 fffe                                   
0000202

Built under Linux: as I'd expect...

bash$ hexdump d.dat
0000000 0100 0302 0504 0706 0908 0b0a 0d0c 0f0e
......
0000100 0100 0302 0504 0706 0908 0b0a 0d0c 0f0e
0000110 1110 1312 1514 1716 1918 1b1a 1d1c 1f1e
......
0000200
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".