From: craft AT alacritech DOT com (Peter Craft)
Subject: Bug in od?
6 Oct 1997 18:00:37 -0700
Message-ID: <34397B15.5577.cygnus.gnu-win32@alacritech.com>
Reply-To: craft AT alacritech DOT com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: gnu-win32 AT cygnus DOT com

AARGH.. what a day.  After a long day of debugging
I discovered that the source of my file corruption
was the result of not specifying the 'b' (binary) argument to
my call to fopen.  In short, when fwriting to a file all
of my 0x0a values got converted to 0x0d0a (carriage
return/line feed).

What made this somewhat more challenging is that
the octal dump (od) of the file did not display the
0x0d values.  Below is a simple program which creates
a file "outfile" and writes 0x0A to it.  Since I open
without the 'b' flag it actually results in the value
0x0d0a getting written to the file.

od -x shows:
testdir==> od -x outfile
0000000 000a 0000
0000004

While a hexl-find-file in emacs shows:
00000000: 0d0a 0000 00                             .....

Surely the od -x output is a bug - not a feature - right?

here is my program:
#include <stdio.h>

main()
{
	FILE			*fp;
	unsigned long	x = 0x0A;

	if(!(fp = fopen("outfile", "a"))) {
		printf("failed to create outfile.  Exiting..\n");
		exit(1);
    }

	if(!fwrite(&x, sizeof(unsigned long), 1, fp)) {
		printf("failed to write to outfile. Exiting \n");
		exit(1);
	}

	fclose(fp);
}
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".