Xref:	news-dnh.mv.net comp.os.msdos.djgpp:3794
Path:	news-dnh.mv.net!mv!news.sprintlink.net!ibm32.perftech.com!usenet
From:	Herb Savage <herb AT perftech DOT com>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Strange bug using 'fwrite'
Date:	Mon, 11 Dec 1995 19:20:01 -0800
Organization:	Performance Technology
Lines:	80
References:	<4agbj6$1vm AT bmerhc5e DOT bnr DOT ca>
Nntp-Posting-Host:	instant.perftech.com
Nntp-Posting-User:	HERB
To:	Chris Butler <cbutler AT bnr DOT ca>
Dj-Gateway:	from newsgroup comp.os.msdos.djgpp

Chris Butler wrote:
> 
> 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");

In text mode in DOS newlines get expanded to carriage-return line-feed
pairs on writing and all carriage returns get removed on reading.

Change the above open statement to
     f2 = fopen("out.2", "wb");

which forces the open to be in binary mode and everything will work
properly.

Herb Savage
herb AT perftech DOT com

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

- Raw text -