write and fwrite send extra bytes when writing binary data to stdout

[Randall R Schulz]

Emilio,

For starters, please put your "cygcheck" output in an uncompressed 
attachment (that is not placed in-line).


You're writing a file in Cygwin's "text" mode, which duplicates the 
line-ending convention of Windows. You were unlucky enough for there to 
be a "newline" octet in your output data and since you didn't indicate 
that the standard output should be treated as binary data, Cygwin 
kindly (or, from your perspective, gratuitously) added a carriage 
return to make a proper (Windows) end-of-line marker.

You'll have to learn about this wrinkle in how Cygwin emulates POSIX 
under Windows while still accommodating the need to produce proper 
Windows text files at certain times.

Check this out: <http://cygwin.com/cygwin-ug-net/using-textbinary.html>.

I'll let someone else chastise you on your other questionable 
programming practices...

Randall Schulz


At 08:53 2003-02-25, Emilio Hernandez-Garcia wrote:
>   Hi all,
>This code is supposed to use 'write' to write in binary format a float 
>array of 12
>elements (thus 4*12=48 bytes) to stdout (on execution it is redirected 
>to a file):
>
>/* ************************************* */
>#include <stdio.h>
>main()  {
>  float const vector[12]={1.,0.2,2.,0.,1.,-1.,512.,512.,0.01,100.,1.,0.};
>  fprintf(stderr," %ld bytes writen to stdout\n",write(1,vector,48));
>}
>/* *************************************** */
>
>- I compile it with gcc 3.2-3 under cygwin 1.3.17-1.
>- The fprintf command tell us that the program has written to stdout 
>48 bytes.  But looking
>at the actual file size, it is of 49 bytes.
>- Examining the file with an hex viewer, there is an extra byte 0D
>between the 8th and the 9th element of the array. This makes the file
>useless to be used by external applications.
>- The extra byte does not appear if you change some of the numbers 
>(for example replace 0.01 by
>0.001) but if you try to write a large enough array, extra bytes 
>always appear somewhere.
>- The same behavior appears by using fwrite(...,stdout). It does not
>happen if fwrite writes to a file open with fopen. I've tried the same 
>code under gcc and
>linux Suse7.*, several versions of c compilers under SGI and HP unix, 
>... ,and the extra bytes never appear.
>
>if you try to read the file generated under cygwin with read (or 
>fread(...,stdin)) the behavior is still
>more curious: the following code reads 'vector' from stdin (which on
>execution is conected to the binary file written before):
>
>/* ************************************** */
>#include <stdio.h>
>main()  {
>        float vector[12];
>        int i;
>        fprintf(stderr,"%ld bytes read\n",read(0,vector,48));
>        for( i=0; i<12; i++){fprintf(stderr,"%f ", vector[i]);}
>}
>/* ************************************** */
>
>The fprintf statement tell us that the program has read 47 bytes, which
>reflects some error. But in fact it has read 49, since all the numbers
>in the file have been read correctly.
>
>Still more: if you read stdin from a file written by the first program under
>linux, where it behaves correctly and outputs 48 bytes, the reading 
>program also
>reads in the numbers correctly, and reports the correct byte count.
>
>All of this is quite puzzling, and frustrating when trying to use cygwin
>to write binary to be piped to other applications.  Any insight?
>
>I attach the output of 'cygcheck -s -v -r > cygcheck.out'
>--
>                Emilio Hernandez-Garcia


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/