strange behavior with fread, fseek

Joe Maimon jmaimon@ttec.com
Thu Jan 26 19:11:00 GMT 2006


Strange to me that is.

Why am I asking here? Perhaps I should make a fool of myself to the 
kernel or glibc people?

Well I know geniuses hang out here. Plus coreutils must have dealt with 
issues like this if it is indeed normal.


$ ls -la fread-fseek.c
-rw-r--r--  1 joe joe 1155 Jan 26 13:37 fread-fseek.c

$ cat fread-fseek.c | wc -l
56

$ cat fread-fseek.c | while ./fread-fseek 1156; do true ; done | wc -l
1

$ cat fread-fseek.c | while ./fread-fseek 1155; do true ; done | wc -l
1

$ cat fread-fseek.c | while ./fread-fseek 1; do true ; done | wc -l
1

$ while ./fread-fseek 1156; do true ; done < fread-fseek.c | wc -l
56

$ while ./fread-fseek 1155; do true ; done < fread-fseek.c | wc -l
1

$ while ./fread-fseek 1; do true ; done < fread-fseek.c | wc -l
1



where the numeric arg is the number of bytes that fread should read per 
call.

Strace shows reads are done in 4096 and _llseek calls look strange.

here is an example

read(0, "#include <stdio.h>\n#include <lib"..., 4096) = 1155
fstat64(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0xb7f2c000
_llseek(0, 1155, [1155], SEEK_SET)      = 0
write(1, "#include <stdio.h>\n", 19#include <stdio.h>

and this is the one where things perform as expected

read(0, "#include <stdio.h>\n#include <lib"..., 4096) = 1155
read(0, "", 4096)                       = 0
fstat64(1, {st_mode=S_IFIFO|0600, st_size=0, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 
0) = 0xb7f6e000
_llseek(0, 0, [0], SEEK_SET)            = 0
read(0, "#include <stdio.h>\n", 19)     = 19
write(1, "#include <stdio.h>\n", 19#include <stdio.h>
)    = 19


Linux nameserver3 2.6.12.3686-smp-0.1.0 #1 SMP Wed Aug 3 21:18:13 EDT 
2005 i686 GNU/Linux

Debian testing




-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fread-fseek.c
URL: <http://sourceware.org/pipermail/glibc-bugs/attachments/20060126/50f69868/attachment.c>


More information about the Glibc-bugs mailing list