nathan@orstcs.UUCP (nathan) (04/03/86)
static inlines: alice!ark claims that "inline" routines are not implicitly static, unless declared otherwise. He/she may be right, in the case of the existing compiler, but Rich Wales is right "by the book". Read section r8.1 more closely: *everything* at the top level is static unless declared otherwise. Doesn't the existing compiler follow this? Nathan C. Myers Address: hplabs!hp-pcd!orstcs!nathan OR nathan@oregon-state Quote: "Laugh-a while you can-a, Monkey-boy" -- John Whorfin
ark@alice.UucP (Andrew Koenig) (04/05/86)
> alice!ark claims that "inline" routines are not implicitly > static, unless declared otherwise. He/she may be right, in > the case of the existing compiler, but Rich Wales is right "by the > book". > > Read section r8.1 more closely: *everything* at the > top level is static unless declared otherwise. Doesn't the > existing compiler follow this? Sorry. I forgot the differences in scoping rules. Maybe Bjarne will clarify the situation.
weh@druny.UUCP (HopkinsWE) (04/07/86)
In article <34200014@orstcs.UUCP>, nathan@orstcs.UUCP (nathan) writes: > static inlines: > > alice!ark claims that "inline" routines are not implicitly > static, unless declared otherwise. He/she may be right, in > the case of the existing compiler, but Rich Wales is right "by the > book". > > Read section r8.1 more closely: *everything* at the > top level is static unless declared otherwise. Section r8.1 is talking about storage class only, not name visibility. The pertinent sections are r4.1, which defines three kinds of scopes: local, file, and class. File scope is that for all objects declared outside of a block or class. It is visible after the point of declaration. Section r4.3 on linkage states that "A name of file scope that is not explicitly declared static is common to every file in a multi-file program; so is the name of a function. Such names are said to be external." > Doesn't the > existing compiler follow this? Mine behaves exactly as specified above (currently that distributed outside AT&T). Regarding inlines specifically, section r4.3 gives more details, but the nature of inlines are that they must be defined in each file where they are used, else the compiler couldn't possibly perform inline expansion. Bill Hopkins rm. 30G11 AT&T Information Systems Labs 11900 N. Pecos St. Denver, CO 80234 (303)538-4944 ihnp4!druny!weh