Date: Tue, 12 Dec 1995 16:18:38 -0500
From: kagel AT quasar DOT bloomberg DOT com
To: cbutler AT bnr DOT ca
Cc: djgpp AT sun DOT soe DOT clarkson DOT edu
Subject: Re: Strange bug using 'fwrite'
Reply-To: kagel AT ts1 DOT bloomberg DOT com

   Errors-To: postmaster AT ns1
   Xref: news-dnh.mv.net comp.os.msdos.djgpp:3784
   Path: news-dnh.mv.net!mv!news.sprintlink.net!news.dpc.net!novia!news.inc.net!news.uoregon.edu!news.dacom.co.kr!newsfeed.internetmci.com!howland.reston.ans.net!plug.news.pipex.net!pipex!dish.news.pipex.net!pipex!bnr.co.uk!bmdhh222.bnr.ca!bcarh8ac.bnr.ca!bcarh8ab.bnr.ca!bmerhc5e.bnr.ca!cbutler
   From: cbutler AT bnr DOT ca (Chris Butler)
   Newsgroups: comp.os.msdos.djgpp
   Date: 11 Dec 1995 04:20:54 GMT
   Organization: Bell-Northern Research Ltd.
   Lines: 65
   Distribution: na
   Nntp-Posting-Host: bmerha40.bnr.ca
   Dj-Gateway: from newsgroup comp.os.msdos.djgpp
   Content-Type: text
   Content-Length: 1829

   Hi folks,

      I was coding away this weekend when the following bug
   stopped me dead.

      I'm using fwrite to write bytes to a file.  Here's a
   program sample:
   --------------------------------
   #include <stdio.h>
   #include <stdlib.h>
   #include <string.h>

   main() {
      FILE *f2;
      char vers_update[5];
      int rec_count = 1;
      short hlength = 2, reclength = 3;
      char extra_bytes[25];
      int i;

      for (i = 0; i < 20; i++)
	 extra_bytes[i] = i + 5;

      strcpy(vers_update, "abcd");
      f2 = fopen("out.2", "w");
      if (f2 == 0) {
	 printf("Couldn't open '%s' for writing... aborting.\n", "out.2");
	 exit(1);
      }

      fwrite(vers_update, 1, 4, f2);
      fwrite(&rec_count, 1, 4, f2);
      fwrite(&hlength, 1, 2, f2);
      fwrite(&reclength, 1, 2, f2);
      fwrite(extra_bytes, 1, 20, f2);
      fclose(f2); 
   }
   ---------------------------- 
   Please, no smart remarks about coding style - I cut & pasted this
   together.  Anyway, when I compile and run this on my PC, I get the 
   following hex dump from the file "out.2":

   61 62 63 64 01 00 00 00  02 00 03 00 05 06 07 08
   09 0d 0a 0b 0c 0d 0e 0f  10 11 12 13 14 15 16 17
   18

   ....for a grand total of 33 bytes, where I was only expecting 32.
   Note also the '0d', second byte on the 2nd line.  Anyone have
   any ideas where it came from?  The program works as I'd expect
   it to on UNIX.  I haven't tried rewriting the above to use
   file descriptors instead of file pointers, so I'm not sure
   what happens there.

      Also, I messed around with the initialization of the 'extra_bytes'
   in other tests - the '0d' always seems to follow the '09'.

   System info:  486 80 MHz CPU, 4 megs RAM, gcc v2.6.3 .

   Any info would be appreciated - thanks.

   -Chris

   -- 
   Chris Butler aka cbutler AT bnr DOT ca -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
	    All standard disclaimers apply.  Have an adequate day.

No bug!  You open the file in text mode, the default in ANSI "C", and wrote a
binary 10 (0x0a), this is a newline which DOS textmode translates to a CR/NL
pair (0x0d0a).  Change the fopen to include the binary mode flag 'b':

       f2 = fopen("out.2", "wb");

BTW:  Same problem using open you must include the O_BINARY flag:

       fd = open( "out.2", O_WRONLY | O_BINARY );

You don't see this under UNIX as UNIX makes no distinction between IO modes.  
The binary mode flags are portable to all ANSI, and most K&R, "C" compilers,
your UNIX version should not balk.

-- 
Art S. Kagel, kagel AT ts1 DOT bloomberg DOT com

The sky is the daily bread of the eyes.  -- Ralph Waldo Emerson