gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/10/86)
In article <1224@ulysses.UUCP> jss@ulysses.UUCP (Jerry Schwarz) writes: >There may have been a recent change of heart, but the Feb 86 draft >stated (D.1.2): > > All external identifiers declared in any of the headers > [enumerated in the standard] are reserved, whether or not > the associated header is included. ... If the program > redefines a reserved external identifier, even with a > sematicaly equivalent form, the behavoir is implementation > defined. > >In other words, the compiler can rely on the standard defined meaning >of any of these functions, e.g. compiling a call to strcpy with an >appropriate block move instruction. But it also says somewhere (I left my copy at home) that one can #undef the function name and be assured that &function_name works, i.e. there must be an external function definition even if the compiler normally takes shortcuts.
kwh@bentley.UUCP (KW Heuer) (04/11/86)
In article <1224@ulysses.UUCP> ulysses!jss (Jerry Schwarz) writes: >>Indeed, X3J11 has decreed that there must be an actual >>extern definition of each required function.... > >There may have been a recent change of heart, but the Feb 86 draft >stated (D.1.2): > > All external identifiers declared in any of the headers > [enumerated in the standard] are reserved, whether or not > the associated header is included. ... This is not necessarily a contradiction; even if strcpy *IS* compiled into a single instruction, there must *ALSO* be a copy in the library so you can take its address. I'm all for optimization, but having the functions built-in disturbs me a little. There are applications that have to run stand-alone; e.g. the UNIX* kernel (which has some functions of its own with names identical to those in libc). Will these have to be renamed to conform to the standard? Perhaps there should be a compiler option to inhibit expansion of builtins? Actually, it seems to me that the correct way to handle it is with an optimizing *loader*. When the loader detects a call to strcpy, and sees that strcpy in libc is small, it could do the inline expansion. Yes, I realize that this requires more information (and smarts) than today's loader has available, but just wait... Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint *UNIX is a trademark of AT&T Bell Laboratories
rwl@uvacs.UUCP (Ray Lubinsky) (04/13/86)
> >C has standard built-in functions???? > Well, how about sizeof(foo)? > > It looks like a function invocation, and is known and understood > by the compiler... The thing is, sizeof() evaluates to a constant at run time, just like 'c'<<3 or BUFSIZ . That makes it a pretty trivial function. All it really does is give you a portable, automatic facility for referring to system dependencies. -- Ray Lubinsky University of Virginia, Dept. of Computer Science UUCP: ...!cbosgd!uvacs!rwl or ...!decvax!mcnc!ncsu!uvacs!rwl
dave@ur-helheim.UUCP (04/16/86)
In article <359@uvacs.UUCP> rwl@uvacs.UUCP (Ray Lubinsky) writes: >> >C has standard built-in functions???? >> >> It looks like a function invocation, and is known and understood >> by the compiler... > >The thing is, sizeof() evaluates to a constant *at run time*, just like >'c'<<3 or BUFSIZ . That makes it a pretty trivial function. All it >really does is give you a portable, automatic facility for referring to >system dependencies. > >Ray Lubinsky University of Virginia, Dept. of Computer Science < * italics mine * > sizeof and BUFSIZ and a good implementation of 'c' << 3 resolve to constants at *compile time*. No run time *evaluation* is necessary. -- "The Faster I Go the Behinder I Get" --Lewis Carroll Dave Carlson {allegra,seismo,decvax}!rochester!ur-valhalla!dave
mac@uvacs.UUCP (Alex Colvin) (04/18/86)
> > >C has standard built-in functions???? > > > Well, how about sizeof(foo)? As has been pointed out, SIZEOF is not a function, it's an operator, like "++". Functions are often built-in in languages such as PASCAL, PL/I, FORTRAN, etc. because they require special syntax (formats in the argument lists, isubs) or information not kept at runtime (size of object, types of arguments). These must be wired in to the compiler. C uses the fixed set of builtin operators for most of these cases. Variable argument lists (printf), the typical sign of a built-in, are handled otherwise in C. See Algol68 for another language with operators but no need for BIFs. Algol68's greatest success seems to be as an influence on C.
joemu@nsc-pdc.UUCP (Joe Mueller) (04/21/86)
> > >C has standard built-in functions???? > > > Well, how about sizeof(foo)? > > > > It looks like a function invocation, and is known and understood > > by the compiler... > > The thing is, sizeof() evaluates to a constant at run time, just like > 'c'<<3 or BUFSIZ . That makes it a pretty trivial function. All it > really does is give you a portable, automatic facility for referring to > system dependencies. > -- Sizeof is an operator, not a function. It's perfectly legal to say "sizeof foo" (without the parens).
jlg@lanl.ARPA (Jim Giles) (04/25/86)
In article <562@nsc-pdc.UUCP> joemu@nsc-pdc.UUCP (Joe Mueller) writes: >Sizeof is an operator, not a function. It's perfectly legal to say >"sizeof foo" (without the parens). An operator is a syntactic form that invokes a function! SIZEOF is clearly a function: it has a domain (actually two domains - data types and variables) and it has a range (the non-negative integers) and it provides a mapping from one to the other. Since that is the mathematical definition of the word 'function', it is clear that SIZEOF is one. Now, it is true that the syntactic description of C uses the term 'function' in a slightly more restrictive way. But the guy that wrote the syntactic description of C just picked 'function' as a convenient name for a grammar rule. If you take it too literally, you will start saying absurd things like "'+' is an operator and not a function." Most people I know would be quite surprised about that! J. Giles Los Alamos
davidsen@steinmetz.UUCP (Davidsen) (05/01/86)
At the first X3J11 conference in Washington DC I had a talk about
builtin procedures with Ralph Ryan of Microsoft. We agreed that it was
a desirable feature and talked about a new "builtin" or "intrinsic"
keyword for inline routines, given the caveat that no implementation
would be *required* to provide them as inline.
At that point, given that we were talking about an "advisory" keyword,
and that obviously you couldn't take the address of an intrinsic
function, one of us suggested that the term "register" be used, since
it may be ignored by the compiler, and prevents taking the address of a
variable.
Consider:
register int foo(n)
int n;
{
/* body */
return (value);
}
Which could be declared in a header file or somewhere, and the form:
register foo();
Which is like an external declaration, but refers to a name known to
the compiler in an implementation. The action if the name were unknown
would be to treat it as "extern".
I had to leave the committee after two years, and nothing really came
of the topic, being bogged down in "const" and "volitile". If there is
an ANSI committee for C1990, I will try to participate again, since the
process is both interesting and effects my environment.
--
-bill davidsen
seismo!rochester!steinmetz!--\
/ \
ihnp4! unirot ------------->---> crdos1!davidsen
\ /
chinet! ---------------------/ (davidsen@ge-crd.ARPA)
"Stupidity, like virtue, is its own reward"kwh@bentley.UUCP (KW Heuer) (05/09/86)
In article <716@steinmetz.UUCP> steinmetz!davidsen (Davidsen) writes: >At that point, given that we were talking about an "advisory" keyword, >and that obviously you couldn't take the address of an intrinsic >function, one of us suggested that the term "register" be used, since >it may be ignored by the compiler, and prevents taking the address of a >variable. I thought of that too! However, I think the meaning is sufficiently different from a register variable that it's better to use a new keyword. >register foo() { ... } >register foo(); You seem to be using the former to mean "inline" and the latter to mean "builtin". These are not the same concept! Also, why should the user have to know which functions are (or might be) builtins? They should be automatically recognized by the compiler unless explicitly disabled. Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint
@hpislx.UUCP (05/09/86)
This message is empty.