Minutes of the 7 January 2010 Teleconference     Austin-473 Page 1 of 1
Submitted by Andrew Josey, The Open Group.             January 8 , 2010

Attendees
Andrew Josey, The Open Group
Don Cragun,  PASC OR
Geoff Clare, The Open Group
Mark Brown, IBM, TOG OR 
Ulrich Drepper, Red Hat

Apologies
Nick Stoughton, USENIX, ISO/IEC OR

We picked up on the current bugs

Bug #140 Realtime signal delivery order Accept as marked
See http://austingroupbugs.net/view.php?id=140
Add a paragraph to the Application Usage section of sigaction() after Issue
7, P1919, L61064:

See also rationale for Realtime Signal Generation and Delivery in Section
B.2.4.2 on page x. 

Bug # 191 getopt and leading + in optstring Accept as marked
http://austingroupbugs.net/view.php?id=191#c329 

Bug # 184 inet_ntop() vs RFC 2553 Rejected
The point for our WG's resolution of "rejected", is that RFC 2553 was
superceded by RFC 3493, and that the Issue 7 Specification matches RFC
3493. It is one of our guiding principles that we align with existing
standards in a given area whenever possible, and RFC 3493 is the current
document for this topic.

As for the reasoning behind RFC 3493, please see those documents or the
IETF. 

Bug #195 Incomplete EILSEQ change in the revision Accept
http://austingroupbugs.net/view.php?id=195 

Bug #196 Improved getsubopt example OPEN
http://austingroupbugs.net/view.php?id=196 
The group thinks the replacement text should not misuse the variable
optarg.  You shouldn't assign a value to it.  Instead create a separate
variable.

As for the const issue: the group considers the cast in the getsubopt call
more desirable.

Request to the submitter (ebb) to please update the issue and have one note explaining all the changes?  


Bug #197 getsubopt needs CX shading Accepted
http://austingroupbugs.net/view.php?id=196 

Bug #162 Determining System Endianess during preprocessing OPEN
This was discussed during today's conference call.
We do not believe that ntohs() should be required to be implemented in any
particular way.

However, if the C Committee does not provide a way to determine endianness
in the next revision of the C Standard, we will consider adding a new
header and macros to specify implementation endianness for integral and
floating point values. 

Action: Nick to review and advice on what the action is at the C committee

Some discussion also occurred on shell pipelines -- Don posted a message
to the group after the call (sequence 13313)

Next Steps
----------
The next call will be on January 21 at 16:00 UK time/08:00 Pacific
to carry on with the defect reports

http://austingroupbugs.net


See the calendar for the list of dialup numbers.

An IRC  channel will be available for the meeting
 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