[BUG] file Truncate is it really busted?
Richard A. O'Keefe
ok at atlas.otago.ac.nz
Tue Nov 27 01:30:48 UTC 2001
"David T. Lewis" <lewis at mail.msen.com> wrote:
p.s. "ftruncate()" is certainly a misleading name. All of the other
"fwhatever()" calls expect to use a FILE structure.
That's about as far from true as you can get.
There is a naming convention in UNIX system calls that
snarkle(...char*...)
operates on a file object, given a pathname for it, while
fsnarkle(...int...)
operates on a file object, given a file descriptor for a connection to it.
Examples:
acl() -vs- facl()
chdir() -vs- fchdir()
chmod() -vs- fchmod()
chown() -vs- fchown()
chroot() -vs- fchroot()
pathconf() -vs- fpathconf()
stat() -vs- fstat()
statvfs() -vs- fstatvfs()
truncate() -vs- ftruncate()
There are also several functions which take a file descriptor argument
and have no analogue with a path-name, such as flock(), fsync(), and
fdatasync(), not to mention fcntl(), which no long-time Unix hacker could
ever forget.
There is also a stdio naming convention that analogues of system
calls such as
snurkle(...int...)
which take a FILE* instead of a file descriptor add an "f" prefix
fsnurkle(...FILE*...)
giving the series
close() -vs- fclose()
open() -vs- fopen()
read() -vs- fread()
lseek() -vs- fseek() [lseek() replaced an older seek()]
write() -vs- fwrite()
The "f" prefix is also generalised to functions which have no system
call analogue.
It is indeed unfortunate that the same prefix is used for both purposes;
blame it on UNIX having originally had a limit of 7 significant characters
in external C identifiers (8 for assembler, but C stuck '_' in front).
It would make sense to have an fftruncate() function (truncate +
f prefix to get file descriptor + f prefix to get FILE*), but there is none.
More information about the Squeak-dev
mailing list
|