From gwyn@arl.army.mil Fri Jun 25 15:39:15 2004 Return-Path: X-Original-To: embedded-c@open-std.org Delivered-To: embedded-c@open-std.org Received: from soiree.arl.army.mil (soiree.arl.army.mil [128.63.39.181]) by ghz.klid.dk (Postfix) with SMTP id 97A1B3760A for ; Fri, 25 Jun 2004 15:39:13 +0200 (CEST) Date: Fri, 25 Jun 2004 09:38:17 EDT From: Doug Gwyn (CISD) To: embedded-c@open-std.org Subject: Re: (embedded-c.208) RE: Corrections on TR 18037 Message-ID: <200406250938.aa03527@soiree.arl.army.mil> > register REG_A int reg_a = 32; > It is however unclear when, and by whom this initialization > should be done (one could imagine that the register storage > onto which the variable maps does not really exist until some > device is initialized by some user code). > Proposal: disallow initializers on named-register variables. In block scope, the initialization is no different from: register REG_A int reg_a; reg_a = 32; So I suppose you mean for the above example to occur at file scope. One possibility is for the C implementation to add these to the list for dynamic initialization, perhaps using an existing C++ static constructor facility. I presume the C implementation's run-time start-up module and/or the program loader take care of allocating all needed resources such as register clusters. > the relationship beween named-registers and 6.9.2 (external > object definitions) need to specified: when there is no > initializer in the named-register declaration, the declaration > is not an external definition for the identifier. The declaration > is however also not a tentative definition, because it has a > storage-class specifier. Then, what is it? That's one problem with using existing syntactic categories for new facilities.. A workaround would be to change storage-class-specifier to storage-class-specifier|whatever in the grammar, where "whatever" is some new category, and then adjust the text that constrains s.c.s. to say the right thing (just s.c.s. or s.c.s.|whatever, depending). Then the construct would not have a s.c.s. and thus would be a tentative definition. > // file 1 > register REG_A int reg_a; > > // file 2 > extern int reg_a; > int main() { return reg_a; } > > According to the new constraints for 6.7.1 this is not allowed: > "If an object is declared with a named-register storage-class > specifier, every declaration of that object shall include the > same named-register storage-class specifier." > The shall implies that a diagnostic is required here. However, so far > C compilers have not been required to diagnose such issues across > translation units. Is this really the intention? I would think that ordinary global int could have quite different linkage properties from a global named register int, so the code needs to be "not allowed". I agree that it is asking too much for a diagnostic, which generally would not be possible at compile time but might have to wait until linking or even program loading. > --- 7.18a.6.1 (fp arithmetic support functions) does not specify > what happens if an integer result overflows. Isn't there a blanket statement to the effect that when a specified result is not representable in the type, the behavior is undefined? If not, there should be.