levy@ttrdc.UUCP (Daniel R. Levy) (04/06/86)
In article <41@cbmvax.cbmvax.cbm.UUCP>, daveh@cbmvax.UUCP writes: >C, LISP, Pascal, BASIC, etc., all have standard built-in functions. C has standard built-in functions???? Gee, that's a new one on me. EVERY function called from C is an external func- tion, or at least it was when C began. This includes things like write(), read(), printf(), math functions, etc. There's no such thing as, for example, a C builtin equivalent to the FORTRAN MAX() or the Basic INPUT which does the right thing no what the arguments' types are, or where the returned result is stored. Of course, C has developed a number of "understood" conventions, like the omnipresence of the write() and read() functions and their calling conven- tions but they are not necessarily gospel. That is, you could compile a function which takes the place of read() and link it in: read() { /* This presumes that write() will remain the "standard" version! */ write(2,"Go fly a kite, I don't feel like reading\n",41); return 0; } and sure 'nuff it would get called, at least in a Unix environment, every time that a program tried to read something through read() or through stdio. (I tried it.) Try that with any of the Basic builtins! I do grant that these conventions like read() and write() have become, through hallowed usage (mostly in Unix) standard enough that some C compilers can get away with treating them as builtins without breaking any code except that which tries to redefine these conventions. VAX/VMS C, for instance, will treat a call of read() as a call of something like C$$READ() while not changing a call of reed() to a call of C$$REED() in analogy. But that is just cosmetic stuff; C in essence still behaves as if all functions (following macro expansions) were external functions, so that (maybe because?) implementations which treat them that way (e.g., Unix) are still quite valid. -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, vax135}!ttrdc!levy
levy@ttrdc.UUCP (Daniel R. Levy) (04/06/86)
In article <41@cbmvax.cbmvax.cbm.UUCP>, daveh@cbmvax.UUCP writes: >C, LISP, Pascal, BASIC, etc., all have standard built-in functions. [O net.lang.c gurus, am I on the mark here? This was originally in net.lang.] C has standard built-in functions???? Gee, that's a new one on me. EVERY function called from C is an external func- tion, or at least it was when C began. This includes things like write(), read(), printf(), math functions, etc. There's no such thing as, for example, a C builtin equivalent to the FORTRAN MAX() or the Basic INPUT which does the right thing no what the arguments' types are, or where the returned result is stored. Of course, C has developed a number of "understood" conventions, like the omnipresence of the write() and read() functions and their calling conven- tions but they are not necessarily gospel. That is, you could compile a function which takes the place of read() and link it in: read() { /* This presumes that write() will remain the "standard" version! */ write(2,"Go fly a kite, I don't feel like reading\n",41); return 0; } and sure 'nuff it would get called, at least in a Unix environment, every time that a program tried to read something through read() or through stdio. (I tried it.) Try that with any of the Basic builtins! I do grant that these conventions like read() and write() have become, through hallowed usage (mostly in Unix) standard enough that some C compilers can get away with treating them as builtins without breaking any code except that which tries to redefine these conventions. VAX/VMS C, for instance, will treat a call of read() as a call of something like C$$READ() while not changing a call of reed() to a call of C$$REED() in analogy. But that is just cosmetic stuff; C in essence still behaves as if all functions (following macro expansions) were external functions, so that (maybe because?) implementations which treat them that way (e.g., Unix) are still quite valid. -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, vax135}!ttrdc!levy
pdg@ihdev.UUCP (P. D. Guthrie) (04/06/86)
In article <824@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >In article <41@cbmvax.cbmvax.cbm.UUCP>, daveh@cbmvax.UUCP writes: >>C, LISP, Pascal, BASIC, etc., all have standard built-in functions. > >C has standard built-in functions???? > >Gee, that's a new one on me. EVERY function called from C is an external func- >tion, or at least it was when C began. You are sort of right, but sizeof qualifies as a builtin function, even though it is a compile-time function vs run-time. Anyone disagree? -- Paul Guthrie `When the going gets weird, ihnp4!ihdev!pdg The weird turn pro' - H. Thompson
gwyn@BRL.ARPA (VLD/VMB) (04/07/86)
Actually, a hosted C implementation must supply a fair number of library functions to qualify as a conforming X3J11 implementation. This is not true of standalone C implementations, however. These functions should not be thought of as "built-in"; indeed, X3J11 has decreed that there must be an actual extern definition of each required function, even when the usual usage would be implemented with preprocessor macros. But the interface IS "standardized" now (or as soon as the official X3J11 standard is approved).
jsdy@hadron.UUCP (Joseph S. D. Yao) (04/08/86)
In article <824@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >C has standard built-in functions???? Well, C has standard (library) functions. C can also have built-in functions to make it standard-conforming. E.g., on machines which do not have instructions to handle longs or floats or doubles or some other standard feature of C (or switch...) the compiler is perfectly justified in setting up code to call a "built-in" function to do this. I know ... I had to write an early version of lmul/ldiv/lrem on the PDP-11, and arrange for FP routines to be trapped to. This is not to be confused with _lmul(), _fdiv(), or anything like that.
meissner@dg_rtp.UUCP (Michael Meissner) (04/08/86)
In article <824@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >In article <41@cbmvax.cbmvax.cbm.UUCP>, daveh@cbmvax.UUCP writes: >> >>C, LISP, Pascal, BASIC, etc., all have standard built-in functions. > >C has standard built-in functions???? > >Gee, that's a new one on me. EVERY function called from C is an external func- >tion, or at least it was when C began. This includes things like write(), >read(), printf(), math functions, etc. There's no such thing as, for example, >a C builtin equivalent to the FORTRAN MAX() or the Basic INPUT which does the >right thing no what the arguments' types are, or where the returned result is >stored. ... That may be the original practice, but the X3J11 (ANSI C) drafts, now quite clearly say that all functions defined in the library are reserved (ie, you can't redefine them), and may be builtin to the compiler. I believe that the /usr/group standard (and probably P1003) reserved every function from all major UNIX* variants. It may be that redefining these reserved library functions will continue to work in *YOUR* implementation, but it's not guaranteed. Michael Meissner, Data General ...{ decvax, ihnp4 }!mcnc!rti-sel!dg_rtp!meissner *UNIX is a trademark of AT&T in the U.S.A. and other countries.
jss@ulysses.UUCP (Jerry Schwarz) (04/09/86)
> > These functions should not be thought of as "built-in"; > indeed, X3J11 has decreed that there must be an actual > extern definition of each required function, even when the > usual usage would be implemented with preprocessor macros. > But the interface IS "standardized" now (or as soon as > the official X3J11 standard is approved). 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. This is the normal meaning of "built-in" function. Jerry Schwarz
eric@chronon.UUCP (Eric Black) (04/09/86)
In article <824@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes: >In article <41@cbmvax.cbmvax.cbm.UUCP>, daveh@cbmvax.UUCP writes: >>C, LISP, Pascal, BASIC, etc., all have standard built-in functions. > >C has standard built-in functions???? > >Gee, that's a new one on me. EVERY function called from C is an external func- >tion, or at least it was when C began. This includes things like write(), >read(), printf(), math functions, etc. There's no such thing as, for example, >a C builtin equivalent to the FORTRAN MAX() or the Basic INPUT which does the >right thing no what the arguments' types are, or where the returned result is >stored. Well, how about sizeof(foo)? It looks like a function invocation, and is known and understood by the compiler... All right, all right, K & R calls it an "operator", but none of us here are known to pick nits, are we?? :-) -- Eric Black "Garbage In, Gospel Out" UUCP: {sun,pyramid,hplabs,amdcad}!chronon!eric
gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/10/86)
In article <202@chronon.UUCP> eric@chronon.UUCP (Eric Black) writes: >Well, how about sizeof(foo)? > >It looks like a function invocation, and is known and understood >by the compiler... Rong. "sizeof" comes in two flavors: sizeof <type-cast> sizeof <object> In the first case, the parentheses belong to the <type-cast>, not to the sizeof syntax; in the second case, surrounding the <object> with parentheses is not usually necessary: int array[20]; ... sizeof array ...
arnold@ucsfcgl.UUCP (Ken Arnold%CGL) (04/10/86)
In article <202@chronon.UUCP> Eric Black writes: >Well, how about sizeof(foo)? > >It looks like a function invocation, and is known and understood >by the compiler... > >All right, all right, K & R calls it an "operator", but none of >us here are known to pick nits, are we?? :-) Not really. If "foo" is a variable, you can just as well say "sizeof foo". You only need the parentheses if "foo" is a type name, e.g., "int". I almost never use "sizeof (type)" since then I have to know which type the variable I am associating it with has. Er, let me try phrasing that in code. some_type *ptr; ptr = malloc(10 * sizeof *ptr); is better (to me) then ptr = malloc(10 * sizeof (some_type)); because it is more true. In the first case I get exactly what I want, in the second I have no guarantee that the size I'm using relates in any way to the type of "ptr". If write the first way, and then change the type of "ptr" to "some_other_type *ptr", life. Purists will note that I really should say ptr = (some_type *) malloc(10 * sizeof *ptr); But eventually malloc() will be of type "void *". This is also an argument for a new "typeof" operator. I presume, however, that ANSI has continued to ignore this, so I guess we're stuck. I'd be glad to be disabused of this notion if someone who has access to the latest draft would tell me. It sure would be nice to look at it sometime before it is officially a proposed standard. Ken Arnold P.S. Another place many people use unecessary parentheses is with "return". About 80% of the people I talk with don't even know they aren't required.
ken@rochester.ARPA (Ipse dixit) (04/11/86)
In article <202@chronon.UUCP> eric@chronon.UUCP (Eric Black) writes: >Well, how about sizeof(foo)? > >It looks like a function invocation, and is known and understood >by the compiler... Ah, but it can be written without the parentheses, i.e. sizeof foo, except when foo is a type, so most people parenthesize it anyway, and don't bother to remember when to and when not to. Ken -- UUCP: ..!{allegra,decvax,seismo}!rochester!ken ARPA: ken@rochester.arpa Snail: CS Dept., U. of Roch., NY 14627. Voice: Ken!
pasm@pur-ee.UUCP (PASM Parallel Processing Laboratory) (04/11/86)
>>C has standard built-in functions???? >> >>Gee, that's a new one on me. EVERY function called from C is an external func- >>tion, or at least it was when C began. > >You are sort of right, but sizeof qualifies as a builtin function, >even though it is a compile-time function vs run-time. Anyone disagree? Yep, I disagree: sizeof is an OPERATOR. See K&R p. 49. You might write something like: sizeof(int) which LOOKS like a function call to the uninitiated, but you can just as correctly write: sizeof int What the heck is a compile-time function? Real useful - functions that return constants. Come on now. (Jim Kuehn; kuehn@ed.purdue.edu; ...ihnp4!pur-ee!kuehn) --jk
kwh@bentley.UUCP (KW Heuer) (04/11/86)
In article <584@ihdev.UUCP> ihdev!pdg (P. D. Guthrie) writes: >... but sizeof qualifies as a builtin function, even though it is a >compile-time function vs run-time. Anyone disagree? Yes, I disagree. The only thing "sizeof" has in common with a "function" (in the C sense) is that it is often written with the argument enclosed in parentheses. (Not always; I've seen "sizeof foo" many times.) It is a function in the mathematical sense, with a domain of "datatype" (though it can also take an expression, which is essentially cast into "datatype"), but I don't think that's what we're talking about here. Karl W. Z. Heuer (ihnp4!bentley!kwh), The Walking Lint
jss@ulysses.UUCP (Jerry Schwarz) (04/11/86)
> You are sort of right, but sizeof qualifies as a builtin function, > even though it is a compile-time function vs run-time. Anyone disagree? It is not a function at all. It is a language construct that syntactically is an operator but sematically is not a function. In the form "sizeof expr" C does not evaluate what appears to be an argument. And in the form "sizeof(type-name)" what appears to be an argument does not have a value.
henry@utzoo.UUCP (Henry Spencer) (04/11/86)
> ... but sizeof qualifies as a builtin function, > even though it is a compile-time function vs run-time. Anyone disagree? Fraid so. Sizeof is an *operator*, which can (but does not have to be) invoked with a function-like syntax. If foo is a variable, "sizeof foo" (note no parentheses) is legitimate. The parentheses are necessary for syntactic reasons when the operand of sizeof is a type -- and if you think this is easy to parse, you should try it sometime! -- but they do not make sizeof a function. -- Support the International League For The Derision Of User-Friendliness! Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
ka@hropus.UUCP (Kenneth Almquist) (04/12/86)
> You are sort of right, but sizeof qualifies as a builtin function, > even though it is a compile-time function vs run-time. Anyone disagree? The sizeof operator doesn't use the function call syntax; it is legal to write "sizeof i" rather than "sizeof(i)". Of course, in the case of "sizeof(int)" the parenthesis are necessary, but since "int" is a reserved word this still doesn't look quite like a function call. Kenneth Almquist ihnp4!houxm!hropus!ka (official name) ihnp4!opus!ka (shorter path)
herndon@umn-cs.UUCP (04/13/86)
I disagree. Sizeof is definitely NOT a function. It is a builtin of the C language, but it is not and could not be written as a function (well...), just as return is definitely not a function. The rules for sizeof are a little peculiar though -- as to when parentheses are required and when they aren't. (For instance, though most people say return(0); the statement return 0; is just as legal.) Sizeof sometimes requires the parentheses. Robert Herndon
pdg@ihdev.UUCP (P. D. Guthrie) (04/14/86)
In article <6584@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> ... but sizeof qualifies as a builtin function, >> even though it is a compile-time function vs run-time. Anyone disagree? > >Fraid so. Sizeof is an *operator*, which can (but does not have to be) >invoked with a function-like syntax. If foo is a variable, "sizeof foo" >(note no parentheses) is legitimate. The parentheses are necessary for >syntactic reasons when the operand of sizeof is a type -- and if you >think this is easy to parse, you should try it sometime! -- but they >do not make sizeof a function. >-- I admit that you are quite correct. Infact when I decided to look this up in the gospel according to K&R, in the index it is listed under 'sizeof operator'. I was thinking of it as a function in a more mathematical (rather than syntactical) sense, but I guess all operators can qualify there (eg. unary minus f(x) = -(x)). I don't know, but I still think that the domain and range of sizeof makes it fit better with functions than operators, but the distinction here is getting murkey. >Support the International League For The Derision Of User-Friendliness! Actually, this is not such a bad idea. There are many times when user friendlyness is a curse. A good example is programs that require a basis of knowledge about the principles used (for instance object-code editors) to do anything. In this example, it is not good to make it easy to modify object code as it encourages this sort of thing. In general, certain actions that should be done with care should not be made simple for anyone to do. This time I won't ask if anyone disagrees as I am sure many people will, but as always thoughtful followups are encouraged, but net.lang is probably not the correct place. > > Henry Spencer @ U of Toronto Zoology > {allegra,ihnp4,decvax,pyramid}!utzoo!henry -- Paul Guthrie `When the going gets weird, ihnp4!ihdev!pdg The weird turn pro' - H. Thompson
levy@ttrdc.UUCP (Daniel R. Levy) (04/16/86)
Looks like I've started a minor ruckus here in net.lang[.c]. The consensus (other than all the quibbling about sizeof) seems to be that C may, but needn't, implement the "standard" functions as wholly external (and thus user-replaceable) in today's world. My original comments to the effect that all C functions are external reflect my impression of the K and R approach to the matter (The comment is very near the front of the book, and specifically makes a point about the I/O functions.) I think that inline expansion would make lots of sense for cases like printf() (which as an external function call must interpret its format at run time when used with a fixed format string). In this case, it could be treated much as Fortran treats formatted I/O statements, parsing the formats at compile time. (Or at least highly efficient For- trans, such as VMS's, do this; a side benefit is that format errors are detected at compile time, catching things like using an integer format to print out a double precision variable, etc. In the case of C, this kind of treatment could catch this kind of error and others which are peculiar to printf and its kin, such as too few or too many arguments after the format.) Someone commented (either on the net or to me) that hosted C language implementations were expected to have an external set of the "standard" functions on hand even if they were treated differently when invoked inline. This kind of makes sense, since C lets a user pass a pointer to a function to another function which is allowed to invoke it by pointer, and it might be desireable to use a "standard" function in that way, e.g., passing strcmp() as a comparison routine to a general purpose searching or sorting routine a la qsort(). Are there other reasons? (Far be it from me to fuel further debate :-) ). -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, vax135}!ttrdc!levy
jsdy@hadron.UUCP (Joseph S. D. Yao) (04/17/86)
In article <6584@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >[unattributed] >> ... but sizeof qualifies as a builtin function, >> even though it is a compile-time function vs run-time. Anyone disagree? >Fraid so. Sizeof is an *operator*, which can (but does not have to be) >invoked with a function-like syntax. ... Any operator which maps its args into a unique value in its range defines an operation which is a function. Just because you can say a + b doesn't mean that (plus a b) [resp., plus(a, b)] is not a function. Similarly, sizeof(i), whether or not you use parens (and I always do) is an operator which, of course, is a function. Were you talking about details of implementation, perhaps? -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}
jj@nrcvax.UUCP (04/19/86)
In article <584@ihdev.UUCP> pdg@ihdev.UUCP (55224-P. D. Guthrie) writes: > >You are sort of right, but sizeof qualifies as a builtin function, >even though it is a compile-time function vs run-time. Anyone disagree? >-- > >Paul Guthrie `When the going gets weird, >ihnp4!ihdev!pdg The weird turn pro' > - H. Thompson 'Sizeof' does not have to look like a function at all. Think of it as a multi-character operator. It seems to be convention to always use 'sizeof(x)' when 'sizeof x' would work the same. The parenthesis are only necessary when 'x' is a type. I guess this is the same as most people using 'return (x)' instead of just 'return x'. -- ------------------------------------------------------------------------- Jeff Jennings Network Research Corp. ihnp4!nrcvax!jj 923 Executive Park Drive Suite C ucbvax!calma!nrcvax!jj Salt Lake City, Utah 84117, U.S.A. {sdcsvax,hplabs}!sdcrdcf!psivax!nrcvax!jj (801) 266-9194
bzs@bu-cs.UUCP (04/20/86)
> What the heck is a compile-time function? Real useful - > functions that return constants. Come on now. Whaddya mean? Macros provide compile time functions. I once wrote a macro in ibm/asmh which yielded the sqrt of it's argument in-line, another which ate lisp-like code and turned it into assembler at 'compile' time. Some constants are useful. Probably depends on your pre-processor whether you have this view. -Barry Shein, Boston University
jso@edison.UUCP (John Owens) (04/24/86)
> You are sort of right, but sizeof qualifies as a builtin function, > even though it is a compile-time function vs run-time. Anyone disagree? > > Paul Guthrie `When the going gets weird, > ihnp4!ihdev!pdg The weird turn pro' > - H. Thompson Yes. Try this on your favorite C compiler and tell me if you still think that "sizeof" is a function as opposed to an operator. main() { int a; printf("%d\n",sizeof a); /* note no parentheses */ } John Owens @ General Electric Company (+1 804 978 5726) edison!jso%virginia@CSNet-Relay.ARPA [old arpa] edison!jso@virginia.EDU [w/ nameservers] jso@edison.UUCP [w/ uucp domains] {cbosgd allegra ncsu xanth}!uvacs!edison!jso [roll your own]
ark@alice.UucP (Andrew Koenig) (04/24/86)
> Any operator which maps its args into a unique value in its range > defines an operation which is a function. Just because you can > say a + b doesn't mean that (plus a b) [resp., plus(a, b)] is not > a function. Similarly, sizeof(i), whether or not you use parens > (and I always do) is an operator which, of course, is a function. > Were you talking about details of implementation, perhaps? The C definition of "function" is not the same as the mathematical definition. A C function is a part of a program. A mathematical function is a set of ordered pairs that meet certain conditions. That said, note that sizeof(i) is syntactically a constant. This would not be true if sizeof were a function.
greg@utcsri.UUCP (Gregory Smith) (04/27/86)
In article <375@hadron.UUCP> jsdy@hadron.UUCP (Joseph S. D. Yao) writes: >In article <6584@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >>[unattributed] >>> ... but sizeof qualifies as a builtin function, >>> even though it is a compile-time function vs run-time. Anyone disagree? >>Fraid so. Sizeof is an *operator*, which can (but does not have to be) >>invoked with a function-like syntax. ... > >Any operator which maps its args into a unique value in its range >defines an operation which is a function. Just because you can >say a + b doesn't mean that (plus a b) [resp., plus(a, b)] is not >a function. Similarly, sizeof(i), whether or not you use parens >(and I always do) is an operator which, of course, is a function. sizeof is NOT a C function ( 'function' is used in the C language sense and not in the mathematical sense ). Operators and functions are distinct in terms of the language definition. Consider the following ( the first two have been posted many times; I have not seen the third one yet ). (1) `sizeof( int * )' is obviously not a function call, but is valid. (2) `sizeof foo' is not a function call, but is valid. (3) `sizeof(foo)' looks like a function call, but is _used_to_obtain_ _symbol_table_information_that_is_not_necessarily_available_at_run_ _time_. It would not be possible to write a run-time function in C or assembler that would act in the same way that sizeof does. E.g. an 'int' would be passed whether 'foo' was 'int' or 'char', so even if you had the ability to measure the size of the parameter block, which is not often the case, it couldn't be done. So enough already ! ! ! ! ! ! ! ! Incidentally, in this sense, a+b is very different from a function. `a+b' does many different things depending on the types of a and b. (a=float, b=int; a=char,b=long etc) A C-callable function of the form plus(a,b) would obviously not do this. Another point: C functions don't even map their args into a unique value. consider getc(f) in the case where f is always the run-time constant 'stdin'. -- "For every action there is an equal and opposite malfunction" ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg
franka@mmintl.UUCP (Frank Adams) (05/01/86)
In article <5341@alice.uUCp> ark@alice.UUCP writes: >The C definition of "function" is not the same as the mathematical >definition. A C function is a part of a program. A mathematical >function is a set of ordered pairs that meet certain conditions. > >That said, note that sizeof(i) is syntactically a constant. This >would not be true if sizeof were a function. Good grief! I am getting very tired of this. You can think of sizeof as a function if you want to, and you can think of it as not being a function if you want to. For some purposes (I haven't noticed any purpose in the discussion so far) one is more useful; for others, the other is. Now will everybody please SHUT UP about the subject? Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Multimate International 52 Oakland Ave North E. Hartford, CT 06108
davidsen@steinmetz.UUCP (Davidsen) (05/02/86)
In article <1700007@umn-cs.UUCP> herndon@umn-cs.UUCP writes: > > I disagree. Sizeof is definitely NOT a function. It is a builtin >of the C language, but it is not and could not be written as a function >(well...), just as return is definitely not a function. Actually sizeof is a unary operator. It applies to the following object, when object is defined as: a variable name a variable type (including all struct and pointer types) the object of indirection of a pointer type Examples: int ka, kb[10], *kc; struct foo sa, *sb; All the same (part 1): sizeof int sizeof (int) sizeof ka sizeof (ka) sizeof *kc sizeof (*kc) (however, sizeof kb == 10*sizeof int) All the same (part 2): sizeof struct foo sizeof (struct foo) sizeof sa sizeof (sa) sizeof *sb sizeof (*sb) -- -bill davidsen seismo!rochester!steinmetz!--\ / \ ihnp4! unirot ------------->---> crdos1!davidsen \ / chinet! ---------------------/ (davidsen@ge-crd.ARPA) "Stupidity, like virtue, is its own reward"