Minutes of the 4th June 2015 Teleconference Austin-711 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 5th June 2015 Attendees: Andrew Josey, The Open Group Don Cragun, IEEE PASC OR Joerg Schilling, FOKUS Fraunhofer Mark Ziegast, SHware Systems Geoff Clare, The Open Group Eric Blake, Red Hat Roger Faulkner, Oracle, The Open Group OR Martin Rehak, Oracle Apologies Nick Stoughton, USENIX, ISO/IEC JTC 1/SC 22 OR Richard Hansen, BBN David Clissold, IBM * General news The IEEE PAR will be considered for approval this week by the IEEE. No additional questions had been received since last week. * Outstanding actions ( Please note that I have flushed this section to shorten the minutes - to locate the last set of outstanding actions, look to the minutes from 26 Feb 2015) Bug 0000887: printf and other functions appear many times in search results OPEN http://austingroupbugs.net/view.php?id=887 Andrew is investigating. Bug 0000900: add qsort_r OPEN http://austingroupbugs.net/view.php?id=900 The consensus was that its a good idea to add the suggested interface. The usual requirements regarding a sponsor for a new interface apply. Action: Open Group OR , to ask the Base WG if they wish to sponsor the additional qsort interface proposed here. Bug 0000901: reserve _POSIX* shell option namespace for future use OPEN http://austingroupbugs.net/view.php?id=901 The forward plan for this bug remains as before: Richard: file a new bug report with a concrete feature that would use the _POSIX* namespace (as motivation for reserving set -o _POSIX*) All: debate the proposed feature. If it's something we want, then revisit bug #901. If not, close bug #901. Bug 0000922: Implementations should be allowed to change/remove implementation-defined environment variables OPEN http://austingroupbugs.net/view.php?id=922 This item remains open. Action on Eric: propose wording for Issue 8 to add secure_getenv(), and make it clear that deleting from environment without explicit request is not compliant, but ignoring is fine. For Issue 7 TC 2: Create new bug to add additional conditions on what makes TMPDIR valid, vs. undefined behavior; also add future directions to getenv() to mention secure_getenv() * Current Business 0000934: Requirement for zeroing the sockaddr_in and sockaddr_un structures. Accepted as marked http://austingroupbugs.net/view.php?id=934 A revised interpretation has been prepared. Andrew has the action to restart the interpretation review clock on this bug. Interpretation response: The standard clearly states that applications need not initialize non-standard members of the sockaddr_in and sockaddr_un structures, and conforming implementations must conform to this. Rationale: Historically some applications initialize just the standard members, and some initialize the whole structure (using default initialization or memset()). There may be applications which do the latter for sockaddr_in and then rely on the zero value of the sin_family member being set to AF_UNSPEC. Therefore the standard should require that AF_UNSPEC has the value 0. Notes to the Editor (not part of this interpretation): On Page: 306 Line: 10238 Section: , change from: The sockaddr_in6 structure shall be set to zero by an application prior to using it, since implementations are free to have additional, implementation-defined fields in sockaddr_in6. to: Prior to calling a function in this standard which reads values from a sockaddr_in6 structure (for example, bind() or connect()), the application shall ensure that all members of the structure, including any additional non-standard members, if any, are initialized. If the sockaddr_in6 structure has a non-standard member, and that member has a value other than the value that would result from default initialization, the behavior of any function in this standard that reads values from the sockaddr_in6 structure is implementation-defined. All functions in this standard that return data in a sockaddr_in6 structure (for example, getaddrinfo() or accept()) shall initialize the structure in a way that meets the above requirements, and shall ensure that each non-standard member, if any, has a value that produces the same behavior as default initialization would in all functions in this standard which read values from a sockaddr_in6 structure. On Page: 309 Line: 10323 change APPLICATION USAGE from: None. to: Although applications are required to initialize all members (including any non-standard ones) of a sockaddr_in6 structure, the same is not required for the sockaddr_in structure, since historically many applications only initialized the standard members. Despite this, applications are encouraged to initialize sockaddr_in structures in a manner similar to the required initialization of sockaddr_in6 structures. Although it is common practice to initialize a sockaddr_in6 structure using: struct sockaddr_in6 sa; memset(&sa, 0, sizeof sa); this method is not portable according to this standard, because the structure can contain pointer or floating point members that are not required to have an all-bits-zero representation after default initialization. Portable methods make use of default initialization, for example: struct sockaddr_in6 sa = { 0 }; or static struct sockaddr_in6 sa_init; struct sockaddr_in6 sa = sa_init; A future version of this standard may require that a pointer object with an all-bits-zero representation is a null pointer, and that sockaddr_in6 does not have any floating-point members if a floating-point object with an all-bits-zero representation does not have the value 0.0. On page 388 after line 13000 insert the following new paragraph: The value of AF_UNSPEC shall be 0. On page 406 after line 13620 (sys/un.h APPLICATION USAGE) insert the following new paragraph: Although applications are required to initialize all members (including any non-standard ones) of a sockaddr_in6 structure (see ), the same is not required for the sockaddr_un structure, since historically many applications only initialized the standard members. Despite this, applications are encouraged to initialize sockaddr_un structures in a manner similar to the required initialization of sockaddr_in6 structures. On page 928 after line 31296 (freeaddrinfo() APPLICATION USAGE) insert the following new paragraph: Although it is common practice to initialize the hints structure using: struct addrinfo hints; memset(&hints, 0, sizeof hints); this method is not portable according to this standard, because the structure can contain pointer or floating point members that are not required to have an all-bits-zero representation after default initialization. Portable methods make use of default initialization, for example: struct addrinfo hints = { 0 }; or static struct addrinfo hints_init; struct addrinfo hints = hints_init; A future version of this standard may require that a pointer object with an all-bits-zero representation is a null pointer, and that addrinfo does not have any floating-point members if a floating-point object with an all-bits-zero representation does not have the value 0.0. On page 107 after line 2884, insert a new 4.x General Concepts section (and renumber subsequent sections as needed): Default Initialization Default initialization causes an object to be initialized according to these rules: if it has pointer type, it is initialized to a null pointer; if it has arithmetic type, it is initialized to (positive or unsigned) zero; if it is an aggregate, every member is initialized (recursively) according to these rules; if it is a union, the first named member is initialized (recursively) according to these rules. For an object of aggregate type with an explicit initializer, the initialization shall occur in initializer list order, each initializer provided for a particular subobject overriding any previously listed initializer for the same subobject; all subobjects that are not initialized explicitly shall be initialized implicitly according to the rules for default initialization. Objects with static storage duration but no explicit initializer shall be initialized implicitly according to the rules for default initialization. An explicit initializer of { 0 } works to perform explicit default initialization for any object of scalar or aggregate type, and for any storage duration. Note: The C standard does not require a compiler to set any field alignment padding bits in a structure or array definition to a particular value. Because of this, a structure initialized using { 0 } might not memcmp() as equal to the same structure initialized using memset() to zero. For consistent results, portable applications comparing structures should test each field individually. Note: If an implementation treats the all-zero bit pattern of a pointer object as a null pointer, and the all-zero bit pattern of a floating point object as equivalent to positive 0, then memset() to zero and calloc() have the same effects as default initialization for all named members of a structure. [MX]Implementations that define __STDC_IEC_559__ guarantee that the all-zero bit pattern of a floating point object represents 0.0.[/MX] Bug #940: all 0 bits should be a null pointer on POSIX systems Accepted as Marked http://austingroupbugs.net/view.php?id=940 At page 72 line 2078 (XBD 3.245 Null Pointer), add a sentence: POSIX additionally guarantees that any pointer object whose representation has all bits set to zero, perhaps by memset() to 0 or by calloc(), will be interpreted as a null pointer. On page 107 after line 2884 (4.x General Concepts) in the section added by 0000934, change: Note: If an implementation treats the all-zero bit pattern of a pointer object as a null pointer, and the all-zero bit pattern of a floating point object as equivalent to positive 0, then memset() to zero and calloc() have the same effects as default initialization for all named members of a structure. [MX]Implementations that define __STDC_IEC_559__ guarantee that the all-zero bit pattern of a floating point object represents 0.0.[/MX] to: Note: If an implementation treats the all-zero bit pattern of a floating point object as equivalent to positive 0, then memset() to zero and calloc() have the same effects as default initialization for all named members of a structure. [MX]Implementations that define __STDC_IEC_559__ guarantee that the all-zero bit pattern of a floating point object represents 0.0.[/MX] On Page: 303 Line: 10107 (XBD DESCRIPTION), add a new paragraph: The addrinfo structure shall not include any additional members which have a floating-point type if an object of that type with an all-bits-zero representation does not have the value 0.0. [MX]Implementations that define __STDC_IEC_559__ are required to treat the all-zero bit pattern for a floating point object as a representation of 0.0, and may therefore have floating-point type members.[/MX] On Page: 305 Line: 10180 (XBD APPLICATION USAGE), change: None. to: The requirement that addrinfo does not include any additional members which have a floating-point type if an object of that type with an all-bits-zero representation does not have the value 0.0 is to allow initialization of an addrinfo hints structure (see XSH freeaddrinfo()) using: struct addrinfo hints; memset(&hints, 0, sizeof hints); as an alternative to the use of default initialization. On Page: 306 Line: 10236 (XBD DESCRIPTION), add a new paragraph: The sockaddr_in6 structure shall not include any additional members which have a floating-point type if an object of that type with an all-bits-zero representation does not have the value 0.0. [MX]Implementations that define __STDC_IEC_559__ are required to treat the all-zero bit pattern for a floating point object as a representation of 0.0, and may therefore have floating-point type members.[/MX] On Page: 309 Line: 10323 (XBD APPLICATION USAGE), after applying 0000934 change: Although it is common practice to initialize a sockaddr_in6 structure using: struct sockaddr_in6 sa; memset(&sa, 0, sizeof sa); this method is not portable according to this standard, because the structure can contain pointer or floating point members that are not required to have an all-bits-zero representation after default initialization. Portable methods make use of default initialization, for example: struct sockaddr_in6 sa = { 0 }; or: static struct sockaddr_in6 sa_init; struct sockaddr_in6 sa = sa_init; A future version of this standard may require that a pointer object with an all-bits-zero representation is a null pointer, and that sockaddr_in6 does not have any floating-point members if a floating-point object with an all-bits-zero representation does not have the value 0.0. to: The requirement that sockaddr_in6 does not include any additional members which have a floating-point type if an object of that type with an all-bits-zero representation does not have the value 0.0 is to allow initialization of a sockaddr_in6 structure using: struct sockaddr_in6 sa; memset(&sa, 0, sizeof sa); as an alternative to the use of default initialization. At page 345 line 11565 (XBD DESCRIPTION), inside CX shading, add a sentence: Additionally, any pointer object whose representation has all bits set to zero, perhaps by memset() to 0 or by calloc(), shall be treated as a null pointer. After page 345 line 11587 (XBD RATIONALE), add a paragraph: Likewise, the ISO C standard does not require a pointer object whose representation has all bits set to zero to be treated as a null pointer. While there has been historical hardware where non-zero patterns were more efficient for use as the canonical null pointer, no known POSIX system has tried to target such hardware. However, though unlikely in modern hardware, a compiler is still allowed to treat more than one bit pattern as a representation of the null pointer (all such patterns will compare equal to one another, and unequal to any pointer to any other object). Thus, applications should not assume that a pointer object with non-zero representation is not a null pointer. On page 928 line 31296 (XSH freeaddrinfo() APPLICATION USAGE), after applying 0000934 change: Although it is common practice to initialize the hints structure using: struct addrinfo hints; memset(&hints, 0, sizeof hints); this method is not portable according to this standard, because the structure can contain pointer or floating point members that are not required to have an all-bits-zero representation after default initialization. Portable methods make use of default initialization, for example: struct addrinfo hints = { 0 }; or static struct addrinfo hints_init; struct addrinfo hints = hints_init; A future version of this standard may require that a pointer object with an all-bits-zero representation is a null pointer, and that addrinfo does not have any floating-point members if a floating-point object with an all-bits-zero representation does not have the value 0.0. to: The hints structure can be initialized using memset(&hints, 0, sizeof hints); or by default initialization (see the APPLICATION USAGE for XBD ). Bug #938: Collation issues in XBD (changes for TC2) Accepted http://austingroupbugs.net/view.php?id=938 (note that a typo was fixed in the bug) Bug #950: troff formatting problem for diff -u/-U output Accepted http://austingroupbugs.net/view.php?id=950 Next Steps ---------- The next call is on June 11, 2015 (a Thursday) Calls are anchored on US time. (8am Pacific) This call will be for the regular 90 minutes. http://austingroupbugs.net An IRC channel will be available for the meeting irc://irc.freenode.net/austingroupbugs An etherpad is usually up for the meeting, with a URL using the date format as below: http://posix@posix.rhansen.org:9001/p/201x-mm-dd password=2115756#