Roland McGrath <[EMAIL PROTECTED]> writes:
> file being truncated to zero and then enlarged. In fact, I believe (I'm
> not bothering to check POSIX even though the book is lying in front of me)
> the user is guaranteed that he can do:
If you ever bother to look it up, please let me know what you find.
(Or perhaps I should get that book for myself. What is a good POSIX
reference?)
> write(file, "data", size)
> ptr = mmap(file, 0, size)
> access ptr -- see "data"
> truncate(file) // could be ftruncate or via a wholly different peropen
> access ptr -- see SEGV(BUS?) in a specified manner
That is quite a harsh behaviour. If you're right, it seems impossible
(I prefer to classify tricks like catching SIGSEGV as impossible) to
write programs that use mmap and fail gracefully on all i/o errors,
bad data, etc. An alternative would be to keep a map of an all-zero
page if the file is truncated. Would it make sense to have a flag to
mmap that enables a different behaviour?
I'm also a little curious about how it works in practice, I've heard
reports saying that reading mmap:ed memory never results in SIGSEGV,
and others saying that it really did segfault under some version of
Solaris when mmap:ed NFS-mounted files were truncated.
I'd be grateful if you or some other knowledgable person could clarify
this.
Regards,
/Niels
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
