[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