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