rkl1@hound.UUCP (K.LAUX) (10/17/88)
In article <8810111921.AA21683@ucbarpa.Berkeley.EDU>, U23405@UICVM.Berkeley.EDU (Michael J. Steiner) writes: > Someone recently said: > >My questions are: > > > > 1. Is it illegal to declare a parameter to be of type `char'? > > 2. If not, is it valid to treat the parameter as type `int'? > > 3. If so, what does the unary `&' operator do to such a variable? > > 4. Where is this addressed in K&R I? > > 5. Where is this addressed in the Draft (assuming no prototypes)? > ---------- > What I would like to know is if all function parameters (formal and actual) > agree in type, will there still be problems with taking the address of a > passed variable, (among other little things)? > > Michael Steiner > Email: U23405@UICVM.BITNET By definition, all function calls are by *value*. Therefore it is permissible to take the address of any argument. The address one will get is *not* the original storage of the variable, but one from the *stack*. If you really want to modify the original storage location, then you would pass the *address* of the variable as an argument to the function. As far as (1) is concerned, it is not illegal to declare a parameter as type 'char'. What you are doing is telling the compiler to treat the parameter as a 'char' within the scope of the function. Therefore, for (2), it is *not* proper to treat it as an 'int' if you haven't declared it as an 'int' (although it was converted to an 'int' and pushed onto the stack before the function was called) --rkl
chris@mimsy.UUCP (Chris Torek) (10/17/88)
In article <8810111921.AA21683@ucbarpa.Berkeley.EDU> U23405@UICVM.Berkeley.EDU (Michael J. Steiner) writes: >What I would like to know is if all function parameters (formal and actual) >agree in type, will there still be problems with taking the address of a >passed variable, (among other little things)? In a dpANS-conformant compiler, and with the exception of array and function parameters (which are rewritten to pointer declarations), no. (I.e., everything will work as expected.) In some existing compilers, yes, unless you stick with `int', `long', `double', and pointer function parameters. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
bill@twwells.uucp (T. William Wells) (10/20/88)
In article <14027@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: : In article <8810111921.AA21683@ucbarpa.Berkeley.EDU> U23405@UICVM.Berkeley.EDU : (Michael J. Steiner) writes: : >What I would like to know is if all function parameters (formal and actual) : >agree in type, will there still be problems with taking the address of a : >passed variable, (among other little things)? : : ... : : In some existing compilers, yes, unless you stick with `int', `long', : `double', and pointer function parameters. What about unsigned int and (for those compilers that support it) unsigned long? --- Bill novavax!proxftl!twwells!bill
chris@mimsy.UUCP (Chris Torek) (10/20/88)
-In article <14027@mimsy.UUCP> I noted that
--In some existing compilers [not conformant with the dpANS], yes, [you
--may have trouble with addresses of function parameters not being pointers
--to the types given in the parameter declarations] unless you stick with
--`int', `long', `double', and pointer function parameters.
In article <104@twwells.uucp> bill@twwells.uucp (T. William Wells) notes:
-What about unsigned int and (for those compilers that support it)
-unsigned long?
Oops; those are also safe.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris