From willemw@ace.nl Tue Jun 22 14:17:42 2004 Return-Path: X-Original-To: embedded-c@open-std.org Delivered-To: embedded-c@open-std.org Received: from ace.ace.nl (212-0-255-130.adsl.easynet.nl [212.0.255.130]) by ghz.klid.dk (Postfix) with ESMTP id 73B1737609 for ; Tue, 22 Jun 2004 14:17:38 +0200 (CEST) Received: from tiwfw (tiwfw.ace.nl [192.168.106.12]) by ace.ace.nl (8.12.5/8.12.5) with SMTP id i5MCHTLe022837; Tue, 22 Jun 2004 14:17:30 +0200 Reply-To: From: "Willem Wakker" To: Cc: "John Hauser" Subject: RE: (embedded-c.207) Corrections on TR 18037 Date: Tue, 22 Jun 2004 14:21:46 +0200 Message-ID: <001101c45853$7c877b00$0c6aa8c0@tiwfw.ace.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 In-Reply-To: <20040619003555.095393760C@ghz.klid.dk> Importance: Normal There are some more problems/issues; I will produce a document with a full list for the pre-Redmond meeting (which I am planning to attend). --- the current specification allows global named-registers to be initialized: 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. --- 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? --- consider // 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? --- the rounding functions in 7.18a.6.3 require that "Fractional bits beyond the rounding point are set to zero in the result"; this should not apply when saturation has occurred. --- 7.18a.6.1 (fp arithmetic support functions) does not specify what happens if an integer result overflows. --- the current text requires that overflow handling is done before rounding; this is counter intuitive, and not what is done for floating-point overflow/rounding. As it happens, the order in which overflow and rounding are done has no effect on the result when saturation is used for overflow handling. Hence, if we change the order, the result remains the same for saturation. However, with the current required order, mod_wrap as overflow handling (which is allowed but not required) cannot (reasonably) be implemented. It is therefore proposed to change the order. - Willem Wakker. aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa Willem Wakker email: cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc ACE Consulting bv tel: +31 20 664 6416 De Ruyterkade 113 fax: +31 20 675 0389 1011 AB Amsterdam, The Netherlands www: http://www.ace.nl eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee > -----Original Message----- > From: John Hauser [mailto:jhauser@jhauser.us] > Sent: Saturday, June 19, 2004 2:38 AM > To: embedded-c@open-std.org > Subject: (embedded-c.207) Corrections on TR 18037 > > > > I have 2 corrections on the text of 18037; to be discussed in > > Redmond for a TC. > > Those two don't look controversial. > > Where do we stand with the other fixes? Here's the list I know of: > > A. Rename "strtok" to "strto_k". (Ugh.) > > B. Remove the definition of "additionally access-qualified version of a > type" from the new text for 6.2.5, and rewrite 6.5 as spelled out in > message embedded-c.195. (Doug Gwyn has suggested replacing the word > "minus" there by "without".) > > Sadly, I also discovered a new problem: > > C. In the new text for 6.7.2.1, the TR adds a constraint: > > The _specifier-qualifier-list_ in the declaration of a member of > a structure or union shall not include an address space > qualifier. > > This is a mistake, because it keeps us from declaring something > innocuous like > > struct onePointer { _X int *pX; }; > > As written, the constraint would make the member declaration > invalid, whereas we only intended to prohibit declarations such as > this: > > struct oneInteger { _X int iX; }; > > I propose we change the constraint to be: > > Within a structure or union specifier, the type of a member > shall not be qualified by an address space qualifier. > > > Willem, will you be attending the Redmond meeting? If not, I could > volunteer to go and be responsible for the TR and/or a TC. > > - John Hauser > > >