Minutes of the 4 April 2013 Teleconference Austin-603 Page 1 of 1 Submitted by Andrew Josey, The Open Group. 5th April 2013 Attendees Don Cragun, PASC OR Andrew Josey, The Open Group Eric Blake, Red Hat Nick Stoughton, USENIX, ISO/IEC OR Jim Pugsley, Oracle Mark Brown, IBM, TOG OR Joerg Schilling, Fraunhofer Society Richard Hansen, BBN Geoff Clare, The Open Group Keld Simonsen * General News Andrew reported that the final pdf of the merged edition had been sent to IEEE. We are still targeting the merged 2013 edition document to be published with IEEE on 19 April 2013. Andrew will check the current status with the ISO secretariat. With the publication of the merged document we will be closing bugs in the Mantis bug tracker, now that they have been applied . This will trigger a number of emails in the system. There are 280 bugs with the tc1-2008 tag. The bugs can be closed in a small number of operations, by selecting them in a filtered list, clicking "Select All" at the bottom left and then select "Close" from the drop-down and click OK. We discussed when to do this. It was agreed we should lock Mantis during the operation and also suppress any emails being generated. Mark agreed to take an action to investigate the steps needed. Andrew had completed his action to review the interpretations status, close any pending interpretations now finalized, and start a 30 day review for proposed interpretations. This included bug 663, which should not have been progressed as its still open and under discussion. Bug 663 was updated to move it off the pending interpretations list. * Old Business +Bug 0000561: NUL-termination of sun_path in Unix sockets OPEN http://austingroupbugs.net/view.php?id=561 Eric has an action to update the proposal. +Bug 0000573: Please add '+' to the portable filename character set OPEN http://austingroupbugs.net/view.php?id=573 Joerg has an action to prepare a proposed change. +Bug 0000592: consistent use of struct timespec OPEN http://austingroupbugs.net/view.php?id=592 This item needs further investigation of existing implementations. Mark reported that AIX does not have a problem with this. Jim notes he is still looking at this. +Bug 0000598: OH shading and new interfaces OPEN http://austingroupbugs.net/view.php?id=598 Eric has an action to propose a new solution with self-contained headers. Bug 0000576: No format specifiers for several types OPEN http://austingroupbugs.net/view.php?id=576 Bug 0000599: Reserved "no thread" value for pthread_t A/M Issue 8 Bug 0000517: EBNF support OPEN http://austingroupbugs.net/view.php?id=517 It was agreed that we need Joerg's input on this item and have left it open for now. Andrew took an action on the 12 September call to notify Joerg (completed after the meeting). * Current Business Bug 0000633: SIGEV_THREAD delivery renders many signal interfaces unsafe OPEN http://austingroupbugs.net/view.php?id=633 This item was again left open pending further feedback. Bug 0000657: Conditions under which fmemopen() write a NUL to the buffer are insufficiently specified OPEN http://austingroupbugs.net/view.php?id=657 Eric has an action to propose wording to clarify the behavior for fmemopen(), and also to contact the glibc developers to get their feedback. Bug 0000656: Clearly allow or forbid thread-local storage for "static" buffers OPEN http://austingroupbugs.net/view.php?id=656 Don has an action to propose wording changes to all of the same places that bug 75 modified. Bug 0000654: unclear behavior of in-line variable assignments preceding functions, special built-ins OPEN http://austingroupbugs.net/view.php?id=654 Richard has volunteered to take an action to draft some words. Bug 0000658: Undefined/unspecified behavior clauses in description of open have race conditions OPEN http://austingroupbugs.net/view.php?id=658 It was noted that there is some overlap with changes in TC1. Eric took an action to update the proposal to resolve the overlaps appropriately. We will pick up with this one next time. A reminder for next week is to look at bug 573 (if Joerg has completed his action) Bug 0000663: Specification of str[n]casecmp is ambiguous Reopened http://austingroupbugs.net/view.php?id=663 We continued this item from last week. Mark had completed his action in bug note 1529. --quote bugnote 1529-- The collating sequence for an EBCDIC (code page 1047) is going to be different than ASCII, I think. Here is some relevant data. Here is the collation table definition from our library part edcclocp.c which is part of the structure of our LC_Collate category. This is used for the static initialization of the POSIX locale, which we instantiate in LE during C initialization. I looked at a couple of alternate initializations that we use, but this is the only one that is relevant for POSIX applications. Character values in the array are decimal. static collel_t _P_colleltbl[]={ 0, 1, 2, 3, 55, 45, 46, 47, 22, 5, 21, 11, 12, 13, 14, 15, 16, 17, 18, 19, 60, 61, 50, 38, 24, 25, 63, 39, 28, 29, 30, 31, 64, 90, 127, 123, 91, 108, 80, 125, 77, 93, 92, 78, 107, 96, 75, 97, 240, 241, 242, 243, 244, 245, 246, 247, 248, 249, 122, 94, 76, 126, 110, 111, 124, 193, 194, 195, 196, 197, 198, 199, 200, 201, 209, 210, 211, 212, 213, 214, 215, 216, 217, 226, 227, 228, 229, 230, 231, 232, 233, 173, 224, 189, 95, 109, 121, 129, 130, 131, 132, 133, 134, 135, 136, 137, 145, 146, 147, 148, 149, 150, 151, 152, 153, 162, 163, 164, 165, 166, 167, 168, 169, 192, 79, 208, 161, 7, 4, 6, 8, 9, 10, 20, 23, 26, 27, 32, 33, 34, 35, 36, 37, 40, 41, 42, 43, 44, 51, 52, 53, 54, 56, 57, 58, 59, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 81, 82, 83, 84, 85, 86, 87, 88, 89, 98, 99, 100, 101, 102, 103, 104, 105, 106, 112, 113, 114, 115, 116, 117, 118, 119, 120, 128, 138, 139, 140, 141, 142, 143, 144, 154, 155, 156, 157, 158, 159, 160, 170, 171, 172, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 190, 191, 202, 203, 204, 205, 206, 207, 218, 219, 220, 221, 222, 223, 225, 234, 235, 236, 237, 238, 239, 250, 251, 252, 253, 254, 255, }; 240 -> 249: Numerals 0 - 9 193 -> 233: Upper case A-Z 129 -> 169: Lower case a-z Here's a pointer to a quick reference to the values for ebcdic code page 1047, which is what z/OS uses. http://en.wikipedia.org/wiki/EBCDIC_1047 [^] The wikipedia table entries show the glyph for printable characters (or acronym for control chars), the corresponding ASCII value, and the decimal value of the EBCDIC slot in the table, which helps in deciphering our static array definition. I believe the ASCII collation sequence is just the numerical ordering of the ASCII code points from 0 - 7F, so it would be fairly easy to show graphically the difference between EBCDIC and ASCII. Also, thinking about it now, there are twice as many possible code points in the EBCDIC collation sequence, so even if the first 127 points matched, as in Unicode, the two orders would be different. Oh well. --end quote-- Eric had followed up with bugnote 1530 --bugnote 1530-- The table is missing collation values for decimal 48, 49, and 62 - what happens when sorting a file with contents $'\x30\n\x31\n\x3e\n\x30\n'? --end bugnote 1530-- Mark has another action to clarify the table he produced in his action. In particular to further identify potential differences between z/OS EBCDIC and the tables in 4-7 and 4-8. Nick also reported that the ISO C meeting has scheduled a discussion on the C locale on April 23, and that it is possible for participants to dial in . The discussion will be at 4pm Amsterdam time. http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1688.htm Bug 0000673: Typo in newlocale Accepted http://austingroupbugs.net/view.php?id=673 This item is tagged for TC2-2008 Bug 0000674: wrong shading for mbtowc() EILSEQ Accepted http://austingroupbugs.net/view.php?id=674 This item is tagged for TC2-2008 Bug 0000675: fcntl(fd, F_SETOWN, pid) error returns OPEN http://austingroupbugs.net/view.php?id=675 The working group started to close this bug as requiring an interpretation and tagging it for TC2-2008. However they felt further information was needed. Action : Andrew followup with Philip Guenther Ask him whether an invalid process group ID and invalid process ID (such as -1) should result in EINVAL or ESRCH when given as the pid value in a call to fcntl(fd, F_SETOWN, pid); Response from Philip (after the meeting) --quote reply from Philip-- I've verified via test program that both Solaris 10 and FreeBSD 8.2 return ESRCH when the pid or pgid can't be found. Linux 2.6.18 (RHEL 5.8) returns success no matter what value is passed to fcntl(F_SETOWN). OpenBSD currently returns success no matter what value is passed to fcntl(F_SETOWN), but I'm working on a diff to change it to return ESRCH. (Side note: on Solaris, no process groups has pgid 1, but on Linux, FreeBSD, and OpenBSD process 1 is in process group 1. Does POSIX actually specify that pgid 1 is invalid?) -end-quote- Next Steps ---------- The next call is on April 11 2013 (a Thursday) Calls are anchored on US time. This call will be for the regular 90 minutes. http://austingroupbugs.net See the calendar for the list of dialup numbers. An IRC channel will be available for the meeting irc://irc.freenode.net/austingroupbugs