Austin Group Minutes of the 20 Nov 2007 Teleconference Austin-410 Page 1 of 1 Submitted by Andrew Josey, The Open Group. Dec 7 , 2007 Attendees Andrew Josey, The Open Group Nick Stoughton, USENIX, ISO/IEC OR Mark Brown, IBM, TOG OR Geoff Clare, The Open Group Apologies Ulrich Drepper, Red Hat Don Cragun , Sun, PASC OR Status update --------------- * ISO Balloting The ISO FCD Ballot was returned, see Austin/409. The results were as expected, and the next step is to return a disposition of comments, which will be to accept them all, and to prepare the next draft (which will be draft 5 for the ISO FDIS ballot). We will invite ISO experts to the next face to face meeting to be held in San Francisco in the week commencing March 3. Action: Andrew to announce the next face to face meeting. Completed. * Draft Status We discussed when the best date to put out draft 4 based on the date of the next face to face meeting and the current interpretations in the pipeline. Its proposed that Draft 4 be the draft for The Open Group company review and simultaneous IEEE ballot, and that the Sanity draft produced (draft 5) after that be submitted as the final IEEE recirculation and the ISO FDIS. Subject to editorial confirmation it was decided that the date for Draft 4 will be January 11, with the Open Group company review to start one week later. This will go for a 30 day IEEE ballot. Issue resolution for the meeting will occur at the face to face meeting in March. * Interps It was that noted that Austin-189 is a duplicate of Austin-185, Andrew to reuse the number We revisited Austin-190 once again based on discussions on the reflector 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, unspecified, or implementation-defined behavior, except in cases where the code is copied directly from the supplied source, or in cases that are documented by the implementation. 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 undefined, unspecified or implementation-defined behavior, except in cases where it is copied directly from the supplied grammar, or in cases that are documented by the implementation. * 2004 Aardvark reports We revised XCU ERN 22 as below: 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 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 either be equivalent to the token decimal-floating-constant as specified by the ISO C standard, or it shall be a sequence of decimal digits and shall be evaluated as an integer constant in decimal. In addition, implementations may accept numeric constants with the form and numeric value equivalent to the tokens hexadecimal-constant and hexadecimal-floating-constant as specified by the ISO C standard. 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 implementations to recognize floating point constants according to either the C89 or the C99 standards, and to allow (but not require) implementations to recognize hexadecimal integer constants. Add to CH The EXTENDED DESCRIPTION is changed to make the support of hexadecimal integer and floating constants optional. XCU ERN 23 Accept as marked below Change XCU page 158 lines 6074-6081 from: and after all the following conversions have been applied, the resulting string would lexically be recognized as a NUMBER token as described by the lexical conventions in Grammar: * All leading and trailing s are discarded. * If the first non- is '+' or '-' , it is discarded. * Changing each occurrence of the decimal point character from the current locale to a period. If a '-' character is ignored in the preceding description, the numeric value of the numeric string shall be the negation of the numeric value of the recognized NUMBER token. Otherwise, the numeric value to: and an implementation-dependent condition corresponding to either (a) or (b) below is met. a. After the equivalent of the following calls to functions defined by the ISO C standard, string_value_end would differ from string_value, and any characters before the terminating null character in string_value_end would be s: char *string_value_end; setlocale(LC_NUMERIC, ""); numeric_value = strtod (string_value, &string_value_end); b. After all the following conversions have been applied, the resulting string would lexically be recognized as a NUMBER token as described by the lexical conventions in Grammar: * All leading and trailing s are discarded. * If the first non- is '+' or '-' , it is discarded. * Each occurrence of the decimal point character from the current locale is changed to a period. In case (a) the numeric value of the numeric string shall be the value that would be returned by the strtod() call. In case (b) if the first non- is '-', the numeric value of the numeric string shall be the negation of the numeric value of the recognized NUMBER token; otherwise the numeric value Append the following text to the awk rationale, after XCU page 185 line 7300: Historical implementations of awk did not support floating-point infinities and NaNs in numeric strings, e.g., "-INF" and "NaN". However, implementations that use the atof() or strtod() function to do the conversion picked up support for these values if they used a C99 version of the function instead of a C89 version. Due to an oversight, the 2001 through 2004 editions of this standard did not allow support for infinities and NaNs, but in this revision support is allowed (but not required). This is a silent change to the behavior of awk programs; for example, in the POSIX locale the expression ("-INF" + 0 < 0) formerly had the value 0 because "-INF" converted to 0, but now it may have the value 0 or 1. XSH ERN 147 XSH tracing Reject Send down the interpretations track, the standard is clear A proper reading of the standard produces this result. 1- write A in stream ( timestamp t1) 2- write B in stream (timestamp t2) 3- write C in stream (timestamp t3). The stream is full. 4- write D in stream (timestamp t4). D overwrites A. The stream is in overflow mode. ( it contains B, C, D) 5- write E in stream (timesamp t5). E overwrites B. The stream is still in overflow mode. (it contains C, D, E) 6- read stream. POSIX_TRACE_OVERFLOW is returned with timestamp set to t1 ( because A has been overwitten). The stream is still in overflow mode. (it contains C, D, E) 7- read stream. C is returned with timestamp set to t3. The stream is no longer in overflow mode.(it contains D, E). D is the first valid entry post-overflow. 8 - write F in stream (timestamp t8). The stream is not in overflow mode. (it contains D, E, F) 9 - read stream. POSIX_TRACE_RESUME is returned with a timestamp set to t4. (this is the time for D) 10- read stream. D is returned with timestamp set to t4. The stream is not in overflow mode.(it contains E, F) 11- read stream. E is returned with timestamp set to t5.(it contains only F). 12- read stream. F is returned with a timestamp set to t8. XCU ERN 175 iconv options Accept Send down the interpretations track (defect) XCU ERN 176 m4 blank Accept as marked below At line 22410, replace: Unquoted s and s preceding each argument shall be ignored. All other characters, including trailing s and s, are retained. with: Unquoted white space characters preceding each argument shall be ignored. All other characters, including trailing white space characters, are retained. (ed note to Cathy: we did note two uses of "whitespace" in the current spec, perhaps these should be "white space") Next Steps ----------- Andrew will update the aardvark reports with the latest inbound defect reports. Andrew will also update the roadmap. The next call will be Thursday 10 January at 16:00 UK 08:00 pacific, 11:00 new york. The call 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