14 Aug
2006
14 Aug
'06
8:35 a.m.
On 8/14/2006 at 2:28 AM Sean Conner wrote:
Ah, but see, an ANSI C compiler is free to treat
memset() "specially" if
you include <string.h>. In fact, ANSI C is free to treat any function in
the Standard C Library (assuming the appropriate header files are
included)
specially, and usually anything in <string.h> is
handled by inlining the
code.
I agree completely--with an optimizing compiler, the result *should* be the
most efficient and the easiest to read when the loop's stated explicitly,
rather than using the memset() call.
First off, you still have to open the file to use
fseek()/ftell(). But
okay, given that, how is the file opened? If in binary mode, yes, this
will work as expected as ftell() for a binary file will return the number
of
charcters from the beginning of the file [1], but for a
text file, the
value returned has no defined meaning except that when passed to fseek()
it will
position the file pointer back to the place when
ftell() was called.
I'm on your side on this one--the question came up "why not use stat(2)?".
My point was that if you couldn't use stat() because it's not ANSI, you
might get away with ftell()--for binary files. If you want to write
portable code and are dealing with counting the number of charactrers, the
only way to do it is to open the file for character input, read it and
count the characters.
I've done my share of porting 'C' code, cursing the idiot who assumed all
of the "Unix-isms" in the original code. The notion of a portable C is
ridiculous. The programming model for C posits far too many things about
the architecture--for instance, the structure of records within a file.
I've used systems where the notion of a record even for the simplest file
is very rigorous and you just can't go and open any old file as binary and
expect anything meaningful. What if the operating system maintains the
notion of a BINARY record as well as a character one? How about those
systems that don't have value-delimited (e.g. \n) character records?
Or doing arithmetic with char types--or what a pointer can point to. Or
the assumption of a binary internal representation. Could you conceive of
a C for an IBM 7080, for example? Did the CDC 6600 ever have a C
implementation? It did have a Pascal compiler as well as PL/I and a bunch
of other languages.
Even a simple statement like:
char
c[100], *pc;
pc = &(c[52]);
can be entirely foreign to a machine's architecture. What if the machine's
not character-addressable? What do the contents of pc mean at that point?
On the other hand, if you want a nice portable language, FORTRAN is pretty
darned close to universal. Pascal--if your system has it--isn't bad
either.
But to this observer, C represents a step backwards in language
development. If it hadn't been for microcomputers, would we even be
talking about C for applications code today?
And is one of the requirements for an architecture today that it be able to
run C? If so, we're all poorer for it.
Cheers,
Chuck