Mail Archives: djgpp-workers/2001/08/26/06:25:33
> > If you call get_magic under 2.03 you can see the problem, but if you
> > call fstat() - which calls get_magic, you don't. So some sequence of
> > additional calls on the handle under 2.03 makes the problem go away.
>
> Didn't Andrew say that he sees the problem even with v2.03?
Yes, calling get_magic on stdin without fstat() first. Not a normal
activity. If you don't redirect, it waits for you to type the magic
number in on the console.
> > The problem specifically is Andrew's original test problem using fstat()
> > on stdin and that causing subsequent calls to read to have missed the
> > first 2 characters in the file.
>
> I think there are several problems that contribute to that. Perhaps we
> should fcator them and decide in what order to handle/fix them.
It looks like seeks work on pipes, so I'm now in the mood to fix seeking
on handle 0. If you are interested in implmentation of pipe techical
details, I'll tell you some other interesting things NT/2K do :-)
The simple fix (see other) is the V2.03 seek to find file length behavior.
> This is a misunderstanding, I think: I was suggesting an extra seek
> inside lseek, not inside _read. I understand that if you call _read
> without seeking in between, everything's dandy.
This is what I was thinking but is different than Andrew's current
patches. But we ought to move the 5 different calls to seek to a single
core routine (say _seek?) instead of patching 5 files
(llseek, filelen, is_exec, lfilelen, lseek).
But if the seek to end behavior provides bug immunity, a much simpler fix.
> > What about having _get_dev_info be smart about these?
>
> You mean, interpret the zero return value as meaning something?
That was a thought, yes. But since seeks work on pipes, we might as well
take advantage of it.
- Raw text -