karl@haddock.UUCP (03/02/87)
In article <13646@sun.uucp> guy@sun.UUCP (Guy Harris) writes: > extern int foo(register int i); > int foo(register int i) { ... } >[These declarations] could cause "i" to be passed in a register. You imply that the declaration "extern int foo(int)" (without "register") is incompatible with the definition "int foo(register int i) { ... }". Does X3J11 really say this? Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint
guy@gorodish.UUCP (03/03/87)
>> extern int foo(register int i); >> int foo(register int i) { ... } >>[These declarations] could cause "i" to be passed in a register. > >You imply that the declaration "extern int foo(int)" (without "register") is >incompatible with the definition "int foo(register int i) { ... }". Does >X3J11 really say this? Unfortunately, what X3J11 says is that the "register" in the declaration would be ignored. It might be nice to have a #pragma or a compiler flag that caused it to pass "i" in a register in this case, although this would require people make sure that function declarations and definitions match - but then, people should make sure of that *anyway*, e.g. by having the declaration in an include file and making sure you include that file in every module that defines a function declared in that include file. One problem with this, though, is that it conflates a specification of the abstract characteristics of the function (namely, the types of its arguments) with the specification of an implementation detail (namely, the machine-language calling sequence for the function), and contradicts the advisory nature of "register" declarations. A #pragma might be a better way of specifying details of the calling sequence; it could also, e.g., indicate which of several instructions are to be used for the call. (I believe BLISS had a notion of this sort.) Again, care would have to be taken to ensure that the #pragma near the declaration agrees with the #pragma near the definition.
drw@cullvax.UUCP (03/11/87)
karl@haddock.UUCP (Karl Heuer) writes: > You imply that the declaration "extern int foo(int)" (without "register") is > incompatible with the definition "int foo(register int i) { ... }". Does > X3J11 really say this? Well, reading section 3.5.3.3, 'register' is specifically allowed for function arguments, and all other storage class specifiers are specifically forbidden. I presume that this means that it is significant in matching, probably so the compiler can pass the argument via a register. Sign! Another ambiguity in X3J11. Dale -- Dale Worley Cullinet Software UUCP: ...!seismo!harvard!mit-eddie!cullvax!drw ARPA: cullvax!drw@eddie.mit.edu Un*x (a generic name for a class of OS's) != Unix (AT&T's brand of such)
greg@utcsri.UUCP (Gregory Smith) (03/13/87)
In article <902@cullvax.UUCP> drw@cullvax.UUCP writes: >Well, reading section 3.5.3.3, 'register' is specifically allowed for >function arguments, and all other storage class specifiers are >specifically forbidden. I presume that this means that it is >significant in matching, probably so the compiler can pass the >argument via a register. Sigh! Another ambiguity in X3J11. > The same specification (re storage class for func arguments) is made in K&R Appendix section 10.1, where it means nothing of the sort. [ I don't have an ANSI draft, but if the above section is your only support, you must be mistaken ] I would think it would be up to the implementors of a compiler/load/runtime environment to make sure that arguments expected in registers are passed in registers. >Dale Worley Cullinet Software -- ---------------------------------------------------------------------- Greg Smith University of Toronto UUCP: ..utzoo!utcsri!greg Have vAX, will hack...
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/14/87)
In article <902@cullvax.UUCP> drw@cullvax.UUCP (Dale Worley) writes: >... Sign! Another ambiguity in X3J11. This issue was pointed out in a public review comment and is being addressed for the next published draft proposed standard. UNOFFICIAL PROGRESS REPORT: It now appears that the next review will not start until around November 1987, several months later than X3J11 were hoping for. (We received too many last-minute comments to deal with in last week's meeting, and several committee members will not be at the June meeting in Paris, so the September 1987 meeting is probably the one that will approve the next public review draft. We're hoping we will have addressed all deficiencies pointed out during the first public review, which officially ended 7 March, so that no substantive changes will be required next time around.) This implies that there will not be an official American National Standard for C until some time in 1988.