>Number: 152485
>Category: misc
>Synopsis: /dev/null seek offset is not reported correctly
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Mon Nov 22 16:10:13 UTC 2010
>Closed-Date:
>Last-Modified:
>Originator: Salvatore Sanfilippo
>Release: FreeBSD 8
>Organization:
VMware
>Environment:
unfortunately I don't have access to the system where the bug was reported /
verified
>Description:
The bug was discovered as a result of a bug in Redis data base Virtual Memory
implementation when running on FreeBSD. Opening /dev/null using the libc
standard I/O functions and writing against it more than 4096 bytes (one memory
page) will result in the seek reported by ftell() to be modulo 4096 (that is,
an incorrect value).
Even if /dev/null is not a standard file it should behave correctly and should
be able to retain the current seek for the open file in a reliable way. I can't
cite standard but I've the feeling the current behavior is not ok, and it's
worth fixing even just because other *BSD kernels and Linux will instead behave
in the obvious least-surprising way.
>How-To-Repeat:
#include <stdio.h>
int main(argc, argv) {
FILE *fp = fopen("/dev/null","w+");
rewind(fp);
int i, len;
for (i=1;i<80000;i++) {
fwrite("t", 1, 1, fp);
len = ftello(fp);
if (len != i) {
printf("Fail on pos: %d, expected to be %d\n", len, i);
return 1;
}
}
printf("Pos is: %d\n", len);
fclose(fp);
return 0;
}
>Fix:
The /dev/null implementation in FreeBSD appears to be optimized for speed, it
allocates a single page of memory and reads from it, writes are completely
discarded. Apparently there is no handling of the offset. But since I've almost
zero clues about the FreeBSD char device API I don't know how a correct
implementation should look like.
>Release-Note:
>Audit-Trail:
>Unformatted:
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "[email protected]"
