Re^2: mmap in Perl?

I´m the author of File::Map. Due to circumstances I can't test or fix this right now, that will have to wait until next week.

This definitely is a bug, I´ll fix it as soon as I´m back home. Data loss as is observed here is not acceptable. Something seems to go wrong in the detection of direct assignment, it should have given a warning and then fix things up.

As for your second question: all other memory mapping modules either have the same issue of requiring substr() assignment to work properly, or use ties which cause the file to be copied completely on each read or write. The latter clearly isn't any better than the former IMSNHO.

Comment on Re^2: mmap in Perl?

Replies are listed 'Best First'.
Re^3: mmap in Perl? by jakobi (Pilgrim) on Oct 21, 2009 at 20:57 UTC
Thanx for checking in, Leon. It's rather as if something detects the assignment of wrong size and silently refuses. So from outside, bug #1 is either in refusing EXOR in being silent about refusing. What kind of behaviour do you intend to provide on wrong-sized assignments (too large, too short, undef <=> replace & pad, overwrite beginning, resize mapping)? I don't remember anything in the module docs about what to expect, IIRC (buglet #2, either mine or your's :) ). cu & thanx, Peter	[reply]
Re^4: mmap in Perl? by Anonymous Monk on Oct 22, 2009 at 12:05 UTC
Bug 1: Due to the way perl's internals work, it is impossible to check the new value until after the assignment has happened. If the assignments goes wrong, perl itself reassigns the variable to another piece of memory. The way I deal with that is checking after every assignment. For some unknown reason that doesn't happen in this case. In other words, the problem is that it doesn't detect what's going on. Bug 2: It is supposed to give you a warning when you're doing something like that. I considered making it an exception, but that may be a little	[reply]