>> ... C library ... (As in Fortran, the
>> practical distinction between intrinsic and external is that in a
>> separate-compilation environment, an external function can't be
>> implemented inline if the user expects to be able to replace it with
>> his own at link time.)
It's useful to be reminded of other aspects of Fortran intrinsics even
if they don't relate to the question "Why isn't C sizeof a function?".
I hoped my phrase "separate-compilation environment" would be
understood to rule out inlining, but evidently not, so I had better
say exactly what I meant: a compiler which is not permitted to see the
entire program at once can still opt to inline an intrinsic, but it
cannot inline an external procedure in the compiler library if that
procedure might be defined in the unseen part.
While my "if the user expects to replace" may seem a quirk, it's at
the heart of the history that explains why "sizeof" isn't a function:
1. Kernighan and Ritchie implemented the original C as a simple
translator emitting code for operators and control flow constructs,
but relying on a "standard C library" for everything that could be
implemented via external functions. Since it couldn't be implemented
via an external function, "sizeof" was an operator. That
implementation remained the de facto definition of C till C89.
2. Users wrote applications which relied on replacing standard C
library functions with their own (occasionally discovering to their
dismay that the library could not provide function X without
duplicating a user-replaced Y.) Compiler-writers confronted the
dilemma of wanting to emit some standard functions inline, but not
wanting to break existing applications in situations where the
compiler is "blind" to part of the program.
3. The C89 standards committee reserved the identifiers provided by
the "standard C library", permitting its functions to be emitted
inline even if the translator is "blind" to part of the program. (As a
concession to existing practice, they described a mechanism by which
implementors could opt to support (2) while still conforming.)
4. Taking advantage of the C89 standard, C compilers today often emit
code inline for a standard C library function like "memcpy" even if
they are "blind" to parts of the program, so in this respect "memcpy"
is now almost as intrinsic as "sizeof", and if one doesn't know the
history of 1-3, it's logical to ask why "sizeof" isn't a function like
"memcpy."
I'm not sure anybody really cares this much, but the standard is at
http://rm-f.net/~orange/devel/specifications/c89-draft.htm and the
rationale is at
http://www.lysator.liu.se/c/rat/d1.html; look for the
section "Use of Library Functions" and follow the references from
there.
