Messages in this thread | | | Date | Mon, 17 Feb 1997 15:39:44 +0200 (SAT) | From | John Carter <> | Subject | RE: B*gg*r mallocs, mmap JOY! |
| |
On Mon, 17 Feb 1997, Michael Weller wrote:
> On Fri, 14 Feb 1997, Christian Hardmeier wrote: > > > On Thu, 13 Feb 1997, John Carter wrote: > > > > > (Note you _can_ use mmap to write to files, the trick is > > > ftruncate()) > > > > > > ftruncate( ofd, st.st_size); // Note this cuty... > > > // ftruncate is not in glibc, its a system call, and works instantaneously. > > > > The behaviour of ftruncate() is OS-dependant when the given length > > exceeds the file's current size. It may or may not work. So if you > > want to write portable code... > > I agree and was quite surprised about this usage of ftruncate. What you > need to do is simply create an empty file of length <n> when you want to > mmap <n> bytes. From my knowledge THE standard way to do so is: > > fseek(fd, <n>, SEEK_SET); > > fflush(fd); /* probably not needed, fseek does that. */ > > mmap(... fileno(fd) ...);
Hokay Folks..... From the "info glibc" on the subject of fseek....
INFO> You can move the stream's file position with `fseek' (*note File INFO> Positioning::.). Moving the file position past the end of the INFO> data already written fills the intervening space with zeroes.
Note that ftruncate does it instananeously. It isn't wasting my time scribbling zero's to disk when I'm about to scribble lots of more interesting things directly thereafter. (It takes a looong time to scribble 400MB of zero's and to then immediately fill it with satellite image. I know. Yawn. Too well. How about a cup of coffee? Has it got around to doing anything useful yet? How about a stroll? Yawn....)
From the "info glibc" on the subject of lseek... INFO> You can set the file position past the current end of the file. INFO> This does not by itself make the file longer; `lseek' never INFO> changes the file. But subsequent output at that position will INFO> extend the file. Characters between the previous end of file and INFO> the new position are filled with zeros. Again, that is no help.
From "man ftruncate" MAN> Truncate causes the file named by path or referenced by fd MAN> to be truncated to at most length bytes in size. If the MAN> file previously was larger than this size, the extra data MAN> is lost. With ftruncate, the file must be open for writ- MAN> ing.
ftruncate does the job and shuts-up. I like ftruncate. So it is a security hole. So what.
So if I'm really curious about what other users are doing on my disk I can ftruncate all the free space and grep around looking for old dirt. So what. Its my disk and as Pournelle's law says, "One user, one (at least) CPU." People are too paranoid. If someone hacks into my machine and does the same to me, well, he will discover spying is the most boring job in the world and go home and take up street sweeping. I _luv_ Linux.
So its not portable.
True. From various other messages I have recieved and from notes in /usr/src/linux/mm/mmap.c there are a lot of nonportable things going on.
Portability is something that happens to Operating System authors. Some of them anyway. Linus. Umm. Err... Not many others I can think of... ;-)) (Hint to would be flamers: I'm poking fun at most other systems I have worked on)
\begin{OFF_TOPIC} But if there is one thing that I have learnt in 20 years of computing is portability matters a lot less than one thinks. (Well, especially less than the marketing department's hype says.)
a) Restricting one self to the Lowest Common Denominator is a very severe restriction. (Think about graphics, ever write a ye olde graphing program using line printer characters? That was portable, Just about nothing else between that level and 200 lines of X calls just to say "Hello World" is portable.)
b) Even code that one ardently believes is portable is not because... i. Standards are such useful things, everyone has their own. ii. When the time comes to port, the problems are different... At the time of the last major port I did, I found... 1) The new software package did 99% of what our old homebrew software did anyway.. 2) Our business had changed so I was off writing entirely new programs anyway. 3) Semantics shift at the most fundamental level, leaving strange mismatches in the best met standards. Eg. VAX/VMS was a Fortran world and hence everything was run by RMS (RECORD Management System) hence the Unix style byte streams and RMS never really quite met properly.
c) New tools become available, new languages provide new opportunities, so I have moved from Fortran to Basic to Algol to Pascal To C To Actor To C++ to ???, and very little got ported along the way.
\end{OFF_TOPIC}
John Carter EMail: ece@dwaf-hri.pwv.gov.za Telephone : 27-12-808-0374x194 Fax:- 27-12-808-0338
Founder of the Council for Unnatural Scientists.
| |