[BUG] file Truncate is it really busted?

Greg A. Woods woods at weird.com
Wed Nov 28 06:51:36 UTC 2001


[ On Tuesday, November 27, 2001 at 14:30:48 (+1300), Richard A. O'Keefe wrote: ]
> Subject: Re: [BUG] file Truncate is it really busted?
>
> 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).

Well there's also the fact that the two uses of the 'f' prefix are
really in fundamentally different levels of the API -- or depending on
your point of view maybe even completely different APIs.  The stdio
library functions that have an 'f' prefix operate on FILE structures.
The system calls that have an 'f' prefix operate on kernel file
descriptors.

> 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.

Actually, no, it doesn't -- but the reasons why depend on one having an
intuitive understanding of the difference in API levels between the
stdio library and raw system calls.

The functions like fclose(), fread(), et al require a FILE* because they
operate on the internal elements of a FILE structure.

If you want to use a system call on a file opened by stdio you simply
access the file descriptor from the (opaque) FILE structure using the
fileno() function.

I.e. there is no need to confuse stdio and system call naming
conventions with ugly constructions like "fftruncate()" because it is
already more properly done with ftruncate(fileno(FILE*)).

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods at acm.org>     <woods at robohack.ca>
Planix, Inc. <woods at planix.com>;   Secrets of the Weird <woods at weird.com>




More information about the Squeak-dev mailing list