Re: [Mingw-users] fwrite: extra byte in my file

[Luke D. <cod...@ho...>]

See the MSDN documentation for fopen(). You have probably heard that text
files in Unix have only a Line Feed (0x0a) marking the end of a line, while
DOS/Windows text files use a Carriage Return & Line Feed combination (0x0d &
0x0a). The MS C runtime is designed to make this difference transparent (to
some degree) to the software, so to disable this conversion you just need to
open the file in binary mode by calling fopen(name, "wb").

Luke Dunstan

----- Original Message -----
From: "Sauron" <Sp...@ml...>
To: <min...@li...>
Sent: Tuesday, December 17, 2002 10:50 AM
Subject: [Mingw-users] fwrite: extra byte in my file


> Let me open with a few apologies. First I am sorry I was unable to search
the archives before
> posting this but I am antsy and it was not available immediately. Second
because I have only been
> programming in C for 4 day (a total of a few hours) I'm sorry if I am
missing something obvious.
> Third I am not a subscriber to this list so please copy me if you have the
answer to my question.
> I'm sorry for the trouble.
>
> I was writing a program to create a BMP. Most of my tests of the current
revision of my program
> worked as expected; the output was a BMP I could open in MSPaint or the
Gimp. I tried
> "myProg.exe 11 11" and I got an eleven by eleven bitmap. But when I tried
"myProg 12 13" the file
> wouldn't open. Upon inspection the file was one byte longer than I
expected it to be. There was an
> extra byte placed between the second and third byte of the BMP, a 0x0D.
(Oddly enough this
> happened on Friday, the 13th of December. Coincidence? Yes, it still
happens on the 16th.) If I
> delete the byte, the file works
> fine. I trimmed away at my program to see if it would go away and it
didn't. Here is my program:
>
> //begin c program
>
> #include <stdio.h>
> #include <string.h>
>
> /* this is and excerpt from a simple program I was writing
> to graph functions in a 24 bit BMP file. It writes a bitmap
> file calculating to see if each pixel's coordinates are a
> solution for the function. This excerpt calculates and
> writes the length of the BMP in bytes to a file as it would
> in the bmp header. */
>
> int main(int argc, char *argv[])
> {
> if (argc<3) return 1;
> FILE *f;
> short int buff;
> int width, height, writeme;
>
> char name[strlen(argv[1]) + strlen(argv[2]) + 6];
> strcpy(name, argv[1]);
> strcat(name, "x");
> strcat(name, argv[2]);
> strcat(name, ".hex");
>
> width=atoi(argv[1]);
> height=atoi(argv[2]);
>
> if (((3*width)%4)==0) buff=0;
> else if (((3*width)%4)==1) buff=3;
> else if (((3*width)%4)==2) buff=2;
> else buff=1;
>
> f=fopen(name,"w");
> if (!f) return 1;
>
> //file size
> writeme=54+(((3*width)+buff)*height);
> fwrite(&writeme,sizeof(int),1,f);
>
> fclose(f);
> printf("%x \n%d \n%s\n",writeme,writeme,name);
>
> return 0;
> }
>
> //end c program
>
> I tried compiling it on two different machines one running win98 the other
winxp. I believe both
> have MinGW 2.0.0. I get the same results. I can't figure out what I'm
doing wrong. When I run
> "myProg 12 13" I expect a 4 byte file: 0x0A020000, but I get 0x0D0A020000.
Could someone
> please tell me what is going on?
>
> Aaron Spike
> Sa...@ml...
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
>