Hi,
The subject says it all... We have some code that scans files
backwards... On the systems we've been running this program on, the
lseek man page typically lists:
[EINVAL] The resulting file offset would be negative.
The following program run under freebsd-current shows the problem:
#include <stdio.h>
#include <errno.h>
#include <unistd.h>
#include <fcntl.h>
main()
{
int offset, myerrno;
int myfd;
myfd = open("/etc/passwd", O_RDONLY);
printf("Seeking to byte 512...\n");
offset = lseek(myfd, 512, SEEK_SET);
myerrno = errno;
printf("offset after first lseek: %d\nerrno=%d\n\n",offset,myerrno);
printf("Seeking relative -1024 bytes...\n");
offset = lseek(myfd, -1024, SEEK_CUR);
myerrno = errno;
printf("offset after second lseek: %d\nerrno=%d\n\n",offset,myerrno);
printf("Current offset location: %d\n",lseek(myfd, 0, SEEK_CUR));
close(myfd);
}
sample output:
Seeking to byte 512...
offset after first lseek: 512
errno=0
Seeking relative -1024 bytes...
offset after second lseek: -512
errno=0
Current offset location: -512
In looking through /usr/src/sys/kern/vfs_syscalls.c I can't see
where we do any validation on the resulting seek location... Do the
appropriate folks think this is a bug? How about posix? Should I
go ahead and submit a pr with a patch?
Thanks!
John
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
