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