Mail Archives: cygwin/2002/09/03/22:33:45
--------------000507010009070101000203
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
OK, this one's really got me stumped and I need to resolve this quickly.
I'd really appreciate any help that can be offered. I'm getting
difference in the behavior of fread (I believe) depending on whether
I've compiled with -mno-cygwin or not. I think this example is simple
enough. Here's the code:
#include <stdlib.h>
#include <stdio.h>
#define BUFLEN (1 << 8)
int main (void) {
FILE *fp;
unsigned char buf [BUFLEN];
long bytes_processed = 0;
int bytes_read;
int i = 0;
int j = 0;
if ((fp = fopen ("sf", "r")) == NULL) {
printf ("Unable to open sf file\n");
exit (1);
} /* if */
while ((bytes_read = fread (buf, 1, BUFLEN, fp)) > 0) {
j = j + bytes_read;
printf ("Pass #%d; %d bytes read this pass; %d total bytes processed
so far\n", ++i, bytes_read, j);
} /* while */
}
Pretty simple eh? Here's how I compile it:
$ gcc foo.c -o foo
$ gcc -mno-cygwin foo.c -o foo.no_cygwin
This little example requires the attached file, named sf. It's merely
/etc/group packed into a file format with some headers and a checksum.
Those additions add binary data to the file which I think is causing the
problems in some strange way because if I use just a plain ASCII copy of
/etc/group as the "sf" file it works OK. However with the attached "sf"
file (with binary data in it) I get the following differing results:
$ foo
Pass #1; 256 bytes read this pass; 256 total bytes processed so far
Pass #2; 256 bytes read this pass; 512 total bytes processed so far
Pass #3; 256 bytes read this pass; 768 total bytes processed so far
Pass #4; 256 bytes read this pass; 1024 total bytes processed so far
Pass #5; 256 bytes read this pass; 1280 total bytes processed so far
Pass #6; 256 bytes read this pass; 1536 total bytes processed so far
Pass #7; 256 bytes read this pass; 1792 total bytes processed so far
Pass #8; 256 bytes read this pass; 2048 total bytes processed so far
Pass #9; 256 bytes read this pass; 2304 total bytes processed so far
Pass #10; 256 bytes read this pass; 2560 total bytes processed so far
Pass #11; 256 bytes read this pass; 2816 total bytes processed so far
Pass #12; 4 bytes read this pass; 2820 total bytes processed so far
$ foo.no_cygwin
Pass #1; 256 bytes read this pass; 256 total bytes processed so far
Pass #2; 256 bytes read this pass; 512 total bytes processed so far
Pass #3; 256 bytes read this pass; 768 total bytes processed so far
Pass #4; 256 bytes read this pass; 1024 total bytes processed so far
Pass #5; 256 bytes read this pass; 1280 total bytes processed so far
Pass #6; 256 bytes read this pass; 1536 total bytes processed so far
Pass #7; 256 bytes read this pass; 1792 total bytes processed so far
Pass #8; 256 bytes read this pass; 2048 total bytes processed so far
Pass #9; 256 bytes read this pass; 2304 total bytes processed so far
Pass #10; 256 bytes read this pass; 2560 total bytes processed so far
Pass #11; 252 bytes read this pass; 2812 total bytes processed so far
As you can see, with -mno-cygwin I only make 11 passes of the loop and
only read a total of 2812 bytes. However without -mno-cygwin I make 12
passes and read a total of 2820 bytes. The question is why?!? The other
question is: Is there a way to get the -mno-cygwin to behave properly.
Thanks in advance.
--------------000507010009070101000203
Content-Type: application/octet-stream;
name="sf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="sf"
AAAAAShjKSBDb3B5cmlnaHQgMjAwMiBTYWxpcmEgT3B0aWNhbCBOZXR3b3JrIFN5c3RlbXMs
IEluYy4AAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAFR1ZSBTZXAgMDMgMTg6MTE6MDUg
MjAwMgAAAAAAAAABAAAAAQAAAAAAAAAAAAAAAAAAAABUdWUgU2VwIDAzIDE2OjAyOjQ5IDIw
MDIAAAAAAAAKVEV2ZXJ5b25lOlMtMS0xLTA6MDoKU1lTVEVNOlMtMS01LTE4OjE4OgpBbGVy
dDpTLTEtNS0yMS0xOTU3OTk0NDg4LTEwMzU1MjU0NDQtNzI1MzQ1NTQzLTEzNTg6MTM1ODoK
Q2FyZWVyczpTLTEtNS0yMS0xOTU3OTk0NDg4LTEwMzU1MjU0NDQtNzI1MzQ1NTQzLTExNjg6
MTE2ODoKQ0NMIERldiBHcm91cDpTLTEtNS0yMS0xOTU3OTk0NDg4LTEwMzU1MjU0NDQtNzI1
MzQ1NTQzLTEyODk6MTI4OToKQ2VydCBQdWJsaXNoZXJzOlMtMS01LTIxLTE5NTc5OTQ0ODgt
MTAzNTUyNTQ0NC03MjUzNDU1NDMtNTE3OjUxNzoKQ2hpbmEgVGVhbTpTLTEtNS0yMS0xOTU3
OTk0NDg4LTEwMzU1MjU0NDQtNzI1MzQ1NTQzLTEzMzM6MTMzMzoKRG5zVXBkYXRlUHJveHk6
Uy0xLTUtMjEtMTk1Nzk5NDQ4OC0xMDM1NTI1NDQ0LTcyNTM0NTU0My0xMTA1OjExMDU6CkRv
bWFpbiBBZG1pbnM6Uy0xLTUtMjEtMTk1Nzk5NDQ4OC0xMDM1NTI1NDQ0LTcyNTM0NTU0My01
MTI6NTEyOgpEb21haW4gQ29tcHV0ZXJzOlMtMS01LTIxLTE5NTc5OTQ0ODgtMTAzNTUyNTQ0
NC03MjUzNDU1NDMtNTE1OjUxNToKRG9tYWluIENvbnRyb2xsZXJzOlMtMS01LTIxLTE5NTc5
OTQ0ODgtMTAzNTUyNTQ0NC03MjUzNDU1NDMtNTE2OjUxNjoKRG9tYWluIEd1ZXN0czpTLTEt
NS0yMS0xOTU3OTk0NDg4LTEwMzU1MjU0NDQtNzI1MzQ1NTQzLTUxNDo1MTQ6CkRvbWFpbiBV
c2VyczpTLTEtNS0yMS0xOTU3OTk0NDg4LTEwMzU1MjU0NDQtNzI1MzQ1NTQzLTUxMzo1MTM6
CkVuZ2luZWVyaW5nOlMtMS01LTIxLTE5NTc5OTQ0ODgtMTAzNTUyNTQ0NC03MjUzNDU1NDMt
MTIwMzoxMjAzOgpFbnRlcnByaXNlIEFkbWluczpTLTEtNS0yMS0xOTU3OTk0NDg4LTEwMzU1
MjU0NDQtNzI1MzQ1NTQzLTUxOTo1MTk6CkV2ZXJ5Ym9keTpTLTEtNS0yMS0xOTU3OTk0NDg4
LTEwMzU1MjU0NDQtNzI1MzQ1NTQzLTExNzA6MTE3MDoKRVZNOlMtMS01LTIxLTE5NTc5OTQ0
ODgtMTAzNTUyNTQ0NC03MjUzNDU1NDMtMjE5NToyMTk1OgpFeGNoYW5nZSBEb21haW4gU2Vy
dmVyczpTLTEtNS0yMS0xOTU3OTk0NDg4LTEwMzU1MjU0NDQtNzI1MzQ1NTQzLTExMDk6MTEw
OToKRXhjaGFuZ2UgU2VydmljZXM6Uy0xLTUtMjEtMTk1Nzk5NDQ4OC0xMDM1NTI1NDQ0LTcy
NTM0NTU0My0xMTM0OjExMzQ6Ckdyb3VwIFBvbGljeSBDcmVhdG9yIE93bmVyczpTLTEtNS0y
MS0xOTU3OTk0NDg4LTEwMzU1MjU0NDQtNzI1MzQ1NTQzLTUyMDo1MjA6CkhhcmR3YXJlOlMt
MS01LTIxLTE5NTc5OTQ0ODgtMTAzNTUyNTQ0NC03MjUzNDU1NDMtMTE5MDoxMTkwOgppbmZv
OlMtMS01LTIxLTE5NTc5OTQ0ODgtMTAzNTUyNTQ0NC03MjUzNDU1NDMtMTMzNzoxMzM3OgpJ
VFN1cHBvcnQ6Uy0xLTUtMjEtMTk1Nzk5NDQ4OC0xMDM1NTI1NDQ0LTcyNTM0NTU0My0xMzgy
OjEzODI6Ck1hcmtldGluZzpTLTEtNS0yMS0xOTU3OTk0NDg4LTEwMzU1MjU0NDQtNzI1MzQ1
NTQzLTIxNjg6MjE2ODoKTmV3czpTLTEtNS0yMS0xOTU3OTk0NDg4LTEwMzU1MjU0NDQtNzI1
MzQ1NTQzLTExNjk6MTE2OToKTk1TIEdyb3VwOlMtMS01LTIxLTE5NTc5OTQ0ODgtMTAzNTUy
NTQ0NC03MjUzNDU1NDMtMTI1NzoxMjU3OgpPcGVyYXRpb25zOlMtMS01LTIxLTE5NTc5OTQ0
ODgtMTAzNTUyNTQ0NC03MjUzNDU1NDMtMTM1NDoxMzU0OgpQYXJ0bmVyczpTLTEtNS0yMS0x
OTU3OTk0NDg4LTEwMzU1MjU0NDQtNzI1MzQ1NTQzLTExNjc6MTE2NzoKUHJvZHVjdDpTLTEt
NS0yMS0xOTU3OTk0NDg4LTEwMzU1MjU0NDQtNzI1MzQ1NTQzLTEzMTg6MTMxODoKUHJvZHVj
dCBUZWFtOlMtMS01LTIxLTE5NTc5OTQ0ODgtMTAzNTUyNTQ0NC03MjUzNDU1NDMtMjE3MToy
MTcxOgpQdXJjaGFzaW5nOlMtMS01LTIxLTE5NTc5OTQ0ODgtMTAzNTUyNTQ0NC03MjUzNDU1
NDMtMTMyNToxMzI1OgpRQTpTLTEtNS0yMS0xOTU3OTk0NDg4LTEwMzU1MjU0NDQtNzI1MzQ1
NTQzLTIxOTg6MjE5ODoKUUI6Uy0xLTUtMjEtMTk1Nzk5NDQ4OC0xMDM1NTI1NDQ0LTcyNTM0
NTU0My0yMTA2OjIxMDY6CnJlcXVlc3Q6Uy0xLTUtMjEtMTk1Nzk5NDQ4OC0xMDM1NTI1NDQ0
LTcyNTM0NTU0My0xNjUwOjE2NTA6ClNhbGVzOlMtMS01LTIxLTE5NTc5OTQ0ODgtMTAzNTUy
NTQ0NC03MjUzNDU1NDMtMTE2NjoxMTY2OgpTYWxlcyZNYXJrZXRpbmc6Uy0xLTUtMjEtMTk1
Nzk5NDQ4OC0xMDM1NTI1NDQ0LTcyNTM0NTU0My0yMTY5OjIxNjk6ClNhbGlyYU1NQ19OZXdz
OlMtMS01LTIxLTE5NTc5OTQ0ODgtMTAzNTUyNTQ0NC03MjUzNDU1NDMtMTIxNjoxMjE2OgpT
Y2hlbWEgQWRtaW5zOlMtMS01LTIxLTE5NTc5OTQ0ODgtMTAzNTUyNTQ0NC03MjUzNDU1NDMt
NTE4OjUxODoKU2VydmljZSBHcm91cDpTLTEtNS0yMS0xOTU3OTk0NDg4LTEwMzU1MjU0NDQt
NzI1MzQ1NTQzLTEyMTU6MTIxNToKU29mdHdhcmU6Uy0xLTUtMjEtMTk1Nzk5NDQ4OC0xMDM1
NTI1NDQ0LTcyNTM0NTU0My0xMzMxOjEzMzE6ClRETSBHcm91cDpTLTEtNS0yMS0xOTU3OTk0
NDg4LTEwMzU1MjU0NDQtNzI1MzQ1NTQzLTEyOTg6MTI5ODoKVHJhbnNwb3J0IEdyb3VwOlMt
MS01LTIxLTE5NTc5OTQ0ODgtMTAzNTUyNTQ0NC03MjUzNDU1NDMtMTIyMDoxMjIwOgp3ZWJt
YXN0ZXI6Uy0xLTUtMjEtMTk1Nzk5NDQ4OC0xMDM1NTI1NDQ0LTcyNTM0NTU0My0xMzM2OjEz
MzY6ChogpS4R5MQ0
--------------000507010009070101000203
Content-Type: text/plain; charset=us-ascii
--
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/
--------------000507010009070101000203--
- Raw text -