Austin Group Minutes of the 20 Nov 2007 Teleconference Austin-408 Page 1 of 1
Submitted by Andrew Josey, The Open Group. Nov 21 , 2007
Attendees
Andrew Josey, The Open Group
Nick Stoughton, USENIX, ISO/IEC OR
Mark Brown, IBM, TOG OR
Geoff Clare, The Open Group
Ulrich Drepper, Red Hat
Don Cragun , Sun, PASC OR
Status update
---------------
* Draft status
Andrew reported interpretations 171-188 have been finalized and
passed to Cathy.
* Interps
Austin-190
There has been some discussion on the reflector concerning
this interpretation which relates to c99 and trailing spaces.
The revised editors notes are now proposed to be as follows:
Add APPLICATION USAGE to c99
In the C Standard the mapping from physical source characters to
the C source character set is implementation-defined. Implementations
may strip whitespace characters before the terminating newline of a
(physical) line as part of this mapping, and as a consequence of
this 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.
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 undefined or unspecified
behavior, except in cases where it is copied directly from the supplied
source. The implementation shall document any implementation-defined
behavior in the generated code, except in cases where it is copied 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 defined or unspecified
behavior, except in cases where it is copied directly from the supplied
grammar. The implementation shall document any implementation-defined
behavior in the generated code, except in cases where it is copied from
the supplied grammar.
* 2004 Aardvark reports
XCU ERN 174 cat RATIONALE Accept
XSH ERN 229 XSH FTMs Accept
XCU ERN 22 awk floating point handling Accept as marked below
We will need to change both normative text and the rationale.
On awk page 157 line 6050
Change from:
A string value shall be converted to a numeric value by the equivalent of
the following calls to functions defined by the ISO C standard:
setlocale(LC_NUMERIC, "");
numeric_value = atof(string_value);
To
A string value shall be converted to a numeric value either by
the equivalent of the following calls to functions
defined by the ISO C standard:
setlocale(LC_NUMERIC, "");
numeric_value = atof(string_value);
or shall be converted to a numeric value by converting the
initial portion of the string to type double representation as follows:
The input string is decomposed into two parts: an initial,
possibly empty, sequence of white-space characters (as
specified by isspace()) and a subject sequence interpreted as
a floating-point constant.
The expected form of the subject sequence is an optional +
or - sign, then a non-empty sequence of digits optionally
containing a period, then an optional exponent part. An exponent
part consists of e or E, followed by an optional sign, followed
by one or more decimal digits.
The sequence starting with the first digit or the period
(whichever occurs first) is interpreted as a floating constant
of the C language, and that if neither an exponent part nor a
period appears, a period is assumed to follow the last digit in
the string. If the subject sequence begins with a minus sign,
the value resulting from the conversion is negated.
Page 177
Change from
8. The token NUMBER shall represent a numeric constant. Its
form and numeric value shall be equivalent to either of the tokens
floating-constant or integer-constant as specified by the ISO C standard,
with the following exceptions:
a. An integer constant cannot begin with 0x or include the hexadecimal
digits 'a', 'b', 'c', 'd', 'e', 'f', 'A', 'B', 'C', 'D', 'E', or 'F'.
b. The value of an integer constant beginning with 0 shall be taken in
decimal rather than octal.
c. An integer constant cannot include a suffix ( 'u', 'U', 'l', or 'L' ).
d. A floating constant cannot include a suffix ( 'f', 'F', 'l', or 'L' ).
To:
8. The token NUMBER shall represent a numeric constant. Its
form and numeric value shall be equivalent to either of the tokens
floating-constant or integer-constant as specified by the ISO C standard,
with the following exceptions:
a. Integer and Floating constants beginning with 0x need not be recognized.
b. The value of an integer constant beginning with 0 shall be taken in
decimal rather than octal.
c. An integer constant shall not include a suffix ( 'u', 'U', 'l', or 'L' ).
d. A floating constant shall not include a suffix ( 'f', 'F', 'l', or 'L' ).
XCU p 185
Replace the following text in rationale 7293:
The description of numeric string processing is based on the behavior
of the atof ( ) function in the ISO C standard. While it is not a
requirement for an implementation to use this function, many historical
implementations of awk do. In the ISO C standard, floating-point constants
use a period as a decimal point character for the language itself,
independent of the current locale, but the atof ( ) function and the
associated strtod( ) function use the decimal point character of the
current locale when converting strings to numeric values. Similarly in
awk, floating-point constants in an awk script use a period independent
of the locale, but input strings use the decimal point character of
the locale.
with
Historical implementations of awk did not parse hexadecimal integer
or floating constants like "0xa" and "0xap0". Due to an oversight,
the 2001 through 2004 editions of this standard required support for
hexadecimal floating constants. This was due to the reference to
atof(). This version of the standard allows but does not require
implementations to use atof() and includes a description of how
floating point numbers are recognized as an alternative to match
historic behavior. The intent of this change is to allow floating
point constants to be recognized as they were in the c89 standard.
Add to CH
The EXTENDED DESCRIPTION is changed to remove the
requirement for support of hexadecimal floating constants .
XCU ERN 23
Geoff take an action , take a similar approach to 22.
XSH ERN 218 poll Accept as marked below
Send down the Interps track
Change first sentence in the POLLHUP error from
The device has been disconnected.
to
A device has been disconnected, or a pipe or FIFO has been
closed by the last process that had it open for writing.
Once set, the hangup state of a FIFO shall persist until some
process opens the FIFO for writing or until all read-only
file descriptors for the FIFO are closed.
Add to RATIONALE
The POLLHUP event does not occur for FIFOs just because the FIFO is not open
for writing.
It only occurs when the FIFO is closed by the last writer and persists until
some process opens the FIFO for writing or until all read-only
file descriptors for the FIFO are closed.
---
For the interpretation RATIONALE response:
The only way to get into this situation is to open the FIFO with O_RDONLY
| O_NONBLOCK.
If the open does not specify O_NONBLOCK, the open() will not return until
an open() for writing occurs; if the writer then closes the FIFO, poll()
on the read-only file descriptor returns with POLLHUP.
So there is no way to test the case of calling read() on a FIFO
opened without the O_NONBLOCK flag unless an open() for write
has already occurred, and this case is covered for POLLHUP.
Next Steps
-----------
Andrew will update the aardvark reports with the latest inbound
defect reports.
The next call will be Thursday 6 December 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