Austin Group Minutes of the 1 Nov 2007 Teleconference Austin-404 Page 1 of 1 Submitted by Andrew Josey, The Open Group. Nov 2 , 2007 Attendees Andrew Josey, The Open Group Geoff Clare, The Open Group Mark Brown, IBM, TOG OR Nick Stoughton, USENIX, ISO/IEC OR Don Cragun , Sun, PASC OR Apologies Ulrich Drepper, Red Hat Status update --------------- * PASC P&P We need to ensure that the changes to the P&P are up to date as otherwise that may delay the C++ PAR. Nick will try and get those back to Lowell as soon as possible. * Austin-175 Add to the editors notes In XCU printf change from: The argument operands shall be treated as strings if the corresponding conversion specifier is b, c, or s; otherwise, it shall be evaluated as a C constant, as described by the ISO C standard, with the following extensions: * A leading plus or minus sign shall be allowed. * If the leading character is a single-quote or double-quote, the value shall be the numeric value in the underlying codeset of the character following the single-quote or double-quote. To: The argument operands shall be treated as strings if the corresponding conversion specifier is b, c, or s, and shall be evaluated as if by the [xref to strtod()] function if the corresponding conversion specifier is a, A, e, E, f, F, g, or G. Otherwise, they shall be evaluated as unsuffixed C integer constants, as described by the ISO C standard, with the following extensions: * A leading plus or minus sign shall be allowed. * If the leading character is a single-quote or double-quote, the value shall be the numeric value in the underlying codeset of the character following the single-quote or double-quote. * Suffixed integer constants shall be allowed [A side effect of this is that the floating-point conversions (if supported) will no longer be required to accept arguments beginning with a leading single-quote or double-quote as per the second extension above. It's an odd requirement, and I doubt if any applications exist that make use of it. Geoff will send in some additional rationale on the above last para.] * 2004 Aardvark reports XCU ERN 22 Open We confirmed that Geoff's response is correct and that we want to allow awk to be implemented using atof() with the C89 or the C99 semantics (although it was never stated in that way). Action : Andrew to email Paul Eggert with this statement XCU ERN 76 c99 Accept as marked below Send down the interpretations track, the standard is silent, refer to sponsor. Add APP USAGE to c99 According to the C standard, one or more white space characters (and no other characters) between a backslash character and the newline character that terminates the line produces implementation-defined results . Portable applications should not use such constructs. For lex and yacc add normative text In d3.2r XCU lex page 2809 Change line 91780 from The C programs shall be generated from lex source code and conform to the ISO C standard to: The C programs shall be generated from lex source code and conform to the ISO C standard, without depending on any implementation-defined behavior, except in cases where it is copied directly from the supplied source. In d3.2r XCU yacc p 3370 l 112806 In DESCRIPTION Insert before the sentence beginning "The C code shall define..." The generated source code shall not depend on any implementation-defined behavior, except in cases where it is copied directly from the supplied grammar. XCU ERN 77 yacc trigraphs Accept as marked below Send down the interps track Change XCU page 1066 lines 41121-41122 (yacc EXTENDED DESCRIPTION) from: The code to be executed shall appear as bodies of text that are intended to be C-language code. to: The code to be executed shall appear as bodies of text that are intended to be C-language code. These bodies of text shall not contain C-language trigraphs. After XCU page 1068 line 41209 (yacc Declarations Section) insert: The body of the union shall not contain unbalanced curly brace preprocessing tokens. After line 41221 insert: The statements shall not contain %} outside a comment, string literal, or multi-character constant. After page 1069 line 41256 insert: The statements shall not contain unbalanced curly brace preprocessing tokens. After XCU page 537 line 20721 (lex EXTENDED DESCRIPTION) insert: C-language code in the input shall not contain C-language trigraphs. The C-language code within %{ and %} delimiter lines shall not contain any lines consisting only of %}, or only of %%. After XCU page 541 line 20899 (Actions in lex) insert: The program statements shall not contain unbalanced curly brace preprocessing tokens. Insert the following paragraph after XCU page 218 line 8610 (c99 RATIONALE): The C standardization committee invented trigraphs (e.g., "??!" to represent "~") to address character-portability problems in development environments based on national variants of the 7-bit ISO 646 character set. However, these environments were already obsolete by the time the first C standard was published, and in practice trigraphs have not been used for their intended purpose. and usually are intended to have their original meaning in K&R C. For example, in practice a C-language source string like "What??!" is usually intended to end in two question marks and an exclamation point, not in "~". Add to c99 APP USAGE Some c99 compilers not conforming to this standard do not support trigraphs by default. Next Steps ----------- Andrew will update the aardvark reports with the latest inbound defect reports. Next calls are Tues 6 and Thur 8 at 16:00 UK 08:00 pacific, 11:00 new york. The calls will last for 90 minutes See http://www.opengroup.org/austin/. An IRC channel will be available for the meeting irc://irc.freestandards.org #austin irc://irc.freestandards.org/austin ICAL: http://www.google.com/calendar/ical/nvctqtstkuni3fab9k3jqtrt4g@group.calendar.google.com/public/basic XML: http://www.google.com/calendar/feeds/nvctqtstkuni3fab9k3jqtrt4g@group.calendar.google.com/public/basic