Document Number: WG14/N1033

WG14/N1033

INCITS/J11/03-002

Kona Meeting Minutes

24-October-2003

Meeting Times:

Tues 21 October 2003 09:30-12:00 13:30-17:00

Wed 22 October 2003 09:00-12:00 13:30-17:00

Thur 23 October 2003 09:00-12:00 13:30-17:00

Fri 24 October 2003 09:00-12:00 13:30-17:00

Meeting Location:

Royal Kona Resort

75-5852 Alii Drive

Kailua-Kona, HI 96740 USA

Meeting Host:

USA / ANSI, Plum Hall

1.0 Opening activities, Tuesday, October 21, 2003

1.1 Opening Comments:

Tom Plum welcomed everybody and described the local arrangements.

1.2 Introduction of Participants/Roll Call

John Benito WG14 Convener USA

Tom Plum Plum Hall USA

Barry Hedquist Perennial, Inc USA

Tom Kremer Cray, Inc USA

John Parks Intel USA

Edison Kwok IBM-Canada USA/Canada

Fred Tydeman Tydeman Consulting USA

P. J. Plauger Dinkumware, Ltd USA

Tana L. Plauger Dinkumware, Ltd USA

Randy Meyers Silverhill Systems USA

Douglas Walls Sun Microsystems USA HOD

Nobu Mori SAP Germany HOD

Francis Glassborrow Self UK HOD

Herb Sutter Microsoft USA/Canada HOD

Jeff Muller Oracle USA

Martyn Lovell Microsoft USA

Mike Cowlishaw IBM-UK UK

Keld Simonsen self Norway HOD

Larry Jones EDS/SDRC USA

David Keaton self USA

Peter Seebach self USA

Rex Jeaschke self USA

Cecilia Galvan Metrowerks USA

Tom MacDonald self USA

Douglas Gwyn US Army USA

1.3 Selection of Meeting Chair

JB to act as meeting chairman.

BH to act as meeting secretary.

1.4 Procedures for this Meeting

As per normal.

1.5 Approval of Previous Minutes (WG14/N1004)

Prior Minutes approved as revised w/o objection. New number N1032

1.6 Review of Action Items and Resolutions

WG14 Action Item List from Oxford

1. ACTION: JB to revise minutes of previous meeting (correct typos) and publish as N1003. DONE - published as N1004

2. ACTION: Randy Meyers - Lvalue of expression - OPEN

3. ACTION: Randy Meyers - Revised words for DR266 - OPEN

4. ACTION: LARRY JONES - DR268 - CLOSED subgroup OTBE

5. ACTION: Randy Meyers - DR267 - DONE

6. ACTION: TOM PLUM to forward N number of C++ Philosophy of revision document to WG14 reflector. No such doc - CLOSED

7. ACTION: NOBU MORI to edit N998 into a form suitable for submission as a TR. DONE

8. ACTION: JB, TOM PLUM, RANDY MEYERS, BILL PLAUGER, WILLEM WAKKER to review the document produced by NOBU MORI. DONE

9. ACTION: JB to forward the reviewed document to SC22 for registration as a TR and concurrent ballot. DONE

10. ACTION: RANDY MEYERS to write the response to DR 284 - OPEN

11. ACTION: FRED TYDEMAN create wording for a DR (number 286 assigned) dealing with correct rounding mode issues in annex F. DONE

12. ACTION: FRED TYDEMAN create wording for a DR (number to be assigned) dealing with one or more 'typo's in G.5.1p8. OPEN, new DR

13. ACTION: FRED TYDEMAN create wording for a DR (number to be assigned) containing floating-point related typos. DONE (merged into 'typo' DR being produced by JB). now DR287

14. ACTION: MARTYN LOVELL to post a request for feedback on the contents of the paper to the WG14 reflector. (C Library Security)

DONE

15. ACTION. RANDY MEYERS to write a paper discussing the issues raised during the discussion of DR 219. OPEN

16. ACTION. RANDY MEYERS, JB to find/create document discussing DR 260.

OPEN

17. ACTION: TOM PLUM to summarize issues associated with DR 236 and provide draft wording for committee response. DONE in meeting.

18. ACTION: RANDY MEYERS to produce wording for DR 284. SAME AS #10 ABOVE

19. ACTION: RAYMOND MAK to create sequence point document and send to review committee in time to comment for submission to the next WG14 meeting. CLOSED

20. ACTION: CLIVE FEATHER, FRED TYDEMAN, RANDY MEYERS, TOM KREMER to review sequence point paper prior to next WG14 meeting. OBE

21. ACTION: FRED TYDEMAN to create a 'flags and sequence points' document for submission as a DR. DONE

22. ACTION: JB to create 'variable -> object typo' document for submission as a DR. DONE

23. ACTION: CLIVE FEATHER to draft words describing the four uses of the term 'constant' to be considered in the response to DR 261. DONE

24. ACTION: WILLEM WAKKER to send document to Embedded subgroup and interested parties on April 14 for a one week review period. DONE

25. ACTION: JB will forward, on April 21, reviewed Embedded document to SC22 for PDTR ballot. DONE

26. ACTION: CLIVE FEATHER to provide modified wording for examples involving flexible array members. DONE IN DR

1.7 Approval of Agenda (WG14/N1018)

Two new agenda items, agenda approved as modified.

1.8 Distribution of New Documents

None

1.9 Information on Next Meeting (WG14/N1022) (Plauger)

PJ: Next meeting to be held in Coogee, Australia during Mar 29 - Apr 2, 2004. Hotel information, etc., provided in N1022. Get reservations by EOY. WG21/C++ will precede the C meeting.

1.10 Identification of National Bodies (Benito)

Countries represented: UK, Canada, US, Germany, Norway

1.11 Identification of J11 voting members (Tydeman)

15 voting J11 members out of 15 possible members.

2. Liaison Activities

2.1 J11 (Walls, Meyers)

Doug Walls - Nothing of note to report.

2.2 WG14 (Benito)

The C Standard was reaffirmed by the Convener at SC22 Plenary in August, in Oslo. We can make a decision to revise the Standard at any time in the future (next 5 years).

2.3 J16/WG21 (Sutter)

Five year revision of C++ is underway.

A revised C++ Standard document, that includes the contents of the TC, has been published as ISO/IEC 14882:2003. Not yet published. This is now the official document. BSI will publish their version in November.

WG21 meeting next week. Ongoing work on several TRs - Performance, Library Extensions, Revised version of the Standard being lead by the evolution working group. Some the evolution group effort will add to language support for the Library Extensions.

Broad liaison exists with WG14. Library TR proposal next week to add the C99 extensions to the C++ Library Extensions.

2.4 WG15 (POSIX) (Simonsen)

Keld - Nothing of note to report. A proposal to disband WG15 was to be presented to SC22, but withdrawn by the US.

[The US TAG to WG15 has been disbanded, and it's duties assumed by US CT22. The US WG15 TAG recommended that WG15 also be disbanded.]

Doug asked how we approach extensions for POSIX issues - who do we talk to. JB pointed out that the Austin Group is the channel to use. FT has been our 'unofficial liaison'.

2.5 WG20 (I18N) (Simonsen)

Keld reported on latest activities of WG20. See N1034, WG20 Liaison Report.

2.6 WG11 (Wakker) - No Report

2.7 Other Liaison Activities

Rex Jeaschke - Free Standards Group has applied to be a Type A liaison to JTC1. Also applied to be a PAS submitter, and then would submit an LSB doc as an ISO Standard.

3. TR Status Report (DTR 18037, WG14/N1006, N1020, N1021) (Benito, Wakker)

From Oxford:

The disposition of comments document has been published for review, along with a new version of the TR. Aiming for SC22 ballot after this meeting and for ballot to be complete before the start of the next WG14 meeting. Some discussion on US-40, for Doug Gwyn. Comes down to US position. If submitted, we can still expect the UK and Switzerland to vote NO. A defect report can be filed against a TR, if needed, DG's concern is that the 'words' don't reflect the 'intent' of the TR.

SC22 has agreed that the final TR can be made publicly available via the web.

4. Rationale Editors report (Benito)

New version of rational is ready, and published in 'The C Standard' by BSI. Will be published to the WG 14 wed site in PDF

5. Defect report status (Benito)

Kona: New summary for DRs posted. Consideration to publishing a new TC, or new version of Std folding in TC1 and TC2.

6. WG14 Standing Document 1 (N1009) (Benito)

This document is titled "WG14 and J11 (C) Joint Mailing and Meeting Information". JB urged all to review this document. Will be SD-1.

7. Disposition of Comments for SC22 N3579 (N1026) (Mori) (Tues Afternoon)

N 3579 - Concurrent Registration and Approval Ballot for PDTR 19769, Specification for additional character data types to the programming language C (Type 2 TR)

Registration Ballot Approved (11,0,2,12), No Comments

PDTR Ballot Approved (11,0,2,12), yes W/comments submitted by Japan (1), Netherlands (1), US (lots)

Comments submitted were reviewed, and proposed responses were generated for each. See N1035.

ACTION: Nubo Mori to generate DOC WG14 (Mori) will prepare a disposition of comments report.

8. Decimal Floating-Point Arithmetic (N1016) (Mak, Cowlishaw) (Tuesday Afternoon)

Mike Cowlishaw gave a slide presentation on decimal arithmetic. Proposal is to develop a TR for decimal floating point arithmetic.

FG believes any work in this area would have a significant impact on C++, suggesting we liaison closely with them on such an effort - assuming both committees want to work on this.

Discussion between DG, MC, and TP on how 'tight' to specify. IEEE 754R, or looser, more generic.

FG prefers to make use of arithmetic operators, rather than relying on libraries; tight implementation; and 'safe' conversions.

KS on record to support the proposal. Asked about making such a proposal to WG21 - likely.

TP believes the future lies in decimal floating point.

further info: http://www2.hursley.ibm.com/decimal

Do we have five national bodies willing to work on this? US, Germany, Canada, Netherlands, and Norway are likely to support the idea.

Much discussion of 'how' to work closely with C++ on this project. Herb suggested having a common editor for both projects, containing 'ifdefs' that delineate the 'C' and 'C++' specifics.

ACTION: JB to forward an NP, submitted by Canada, for a Type 2 TR for this effort to SC22 for ballot.

9. C Library Security (N1031) (Meyers) (Thurs)

Proposed Technical Report for extensions to the C99 library. These extensions are intended to promote "safer, more secure programming".

Slide / discussion presentation by Randy Meyers. (N1036)

Don't provide new functions where safe functions already exist.

Q: Use of a single macro, __USE_SECURE_LIB__ -or- simple add new functions to existing headers? Use a TR number vice the above? A feature macro usually implies all or nothing. General agreement on a feature macro, although of a different name - small prize offered for a 'better name'.

Use of errno: zero is success, ERANGE used to indicate output buffer is too small. Setting errno is optional.

Add a new type via typedef, i.e. 'int typedef errcode_t' - general support for this.

Q: Making the return value an indication of success and failure? Yes. DG: three options, including doing nothing, favors the proposed.

Q: Make the return an errno value? Yes

Q: use errcode_t as the return type when errno returned? Concern about namespace collision - someone has got to be using this already?

Straw Poll on exact type spelling:

1. Spelling from reserved identifiers and future library directions - 9

2. errcode_t - 11

3. errno_t - 12

After discussion, gen consensus on errno_t.

Walked thru the document (N1031)

Sec 1 - Scope - KS interested in a possible merging of the effort he is presenting on Friday with this one. Conclusion: TBD-If we need to change the scope at some point we can do so, but not to do so right now.

Sec 2 - Needs reference to TC-1

3.1.1#1 - two 'onlys' -- remove one

3.2.1.1 - potential security hole (namespace collision) - add I-D footnote

3.2.1.1 - general issue of creation of an 'exclusive' tmp file as a side effect, possible new function.

3.2.1.1#4 needs words added to address any interactions w/tmpnam.

3.2.2.2 scanf_s general (from chart)

Failing scanf_s:

- variables not successfully read into by scanf_s should be set to values designed to prevent accidental uses of those variables

scanf_s("%s%s", a, sizeof a, b, sizeof b);

- If scanf_s returns 1 because of EOF prevented reading b, then b[0] should be set to '\0'.

Straw Poll

1. Favor of having scanf_s set to safe values of unmatched input items - lots to 2

3.3.1.1 - rand_s

Expect a better description in the next draft. Existing text is a 'place-holder'. Might exploit a hardware random number generator. Might lack a user specified seed, and the ability to restart a sequence of random numbers.

DG: If we want a 'real' random number generator, we need to be able to specify physical randomness, but there is no advantage in us trying to help those who need that capability. Fear is that we provide a false sense of security with this approach.

RM: Difficult to specify the 'goodness' of such a capability.

FG: We are not going to be able to specify a RNG that meets the real needs of high level cryptography for security. PJ suggested looking at the C++ TR that addresses RNG - well done, and a model that may work for us. TP - we could make the capability of the RNG imp-def to meet the needs of the marketplace.

DG - suggested deleting the 'pseudo-' in the text; change range "0 thru RAND_S_MAX"

3.3.2.1 getenv_s

General Items - UNIX Compatibility

-Functions similar to, or inspired by the Single UNIX Spec.

-Closer comparison to SUS will accompany the next draft.

Other issues:

How to deal with locale specific functions.

How to know that a name exists.

How to return the length of the string.

Straw Vote

Favor of changing interface to include an indication of the number of characters needed upon failure - lots, opposed 0.

3.3.3 - edits from DG - provided via hcopy to RM

3.3.3.2#3 qsort_s - move description of 3rd argument before return value.

3.4.1.1#3 redundant statement, but keep.

3.4.1.3#5 strncpy_s - some discussion on making the concepts of #5 global, DG recommends keeping it to str*_s.

DG to provide suggested edits to RM before Friday.

3.4.1.3#2 - add 'no copying is performed'.

Straw Polls:

1. Favor of license given #5 - yes

2. favor of #5 apply globally => str*_s functions as applicable

3. for or against of NULL padding like strncpy? - NO

3.4.2.1 strncat_s

ACTION: DG - to provide hard copy edits to RM - DONE

DG: #7 not correct to be 'undefined behavior' - thinks it should be removed. TP would like a footnote clarifying the intent of #7, 'restrict' states the restriction with more clarity. Removing the paragraph might cause more confusion, which is why the footnote would help - but doing so is also awkward. RM will 'see what he can do with this'.

#4 - change font of 'm'

#9 - changes of "sn will be the sequence" vs "sn will point to the sequence.."

3.4.3.1 strtok_r - should be aligned with SUS, RM will check.

DG #5 - searches for the 'first' character vice searches for 'a' character.

Give strong consideration to renaming this to strtok_s to avoid conflict.

3.4.4.2 strlen_s

DG comments to be submitted.

3.5.1 - RM: need to fix type, or function of use of strncpy_s.

3.5.1.1 asctime_s

DG - not using a normalized broken down time, need to use safe functions, snprintf? RM will rework.

3.5.1.2 - basically a wrapper for asctime_s, so corrections to that will correct this.

Additional Stuff to consider:

Should there be an annex listing functions to be avoided in favor of the new functions? In favor - lots.

Should there be sections that address QOI issues, such a compiler flags, parameter validation, checks for NULL pointers, etc.? YES - this info could go in a rationale.

Should there be a rationale? YES (all TRs should have a rationale)

Should there be a predefined macro that says the library is available. NO, keep it confined to individual headers.

Other possible new functions: strcpy_s; strcat_s; wcscpy_s; wcscat_s. Would be convenient - general agreement to include.

10. Potential Defect Reports (N1012, N1015, N1017, N1024, N1025) (Plauger, Tydeman, Benito) (Tuesday Afternoon)

Purpose of this session is to determine if an item is a DR, then assign it a DR number.

N1012 - deficiency on multibyte conversions

DEFECT - DR-288

N1015 - 6.7.6 (direct-abstract-declarator) is inconsistent with 6.7.5 (direct-declarator) with respect to omitting an identifier from a declaration to form a type name. (Tydeman)

DEFECT - DR-289

N1017 - FLT_EVAL_METHOD says that ALL floating-point operations and operands are evaluated to a format whose range and precision may be greater than required by the type. This contradicts descriptions of assignment and cast. It may contradict return. It may contradict argument passing. It may contradict register variables. (Tydeman)

DEFECT - DR-290

N1024 - Corrections to requirements on inexact floating-point exceptions. (Plauger)

DEFECT - DR-291

N1025 - Change the use of 'variable' to 'object' where the Standard is referring to an object. (Benito)

DEFECT - DR-292

DR-293: Typo in Standard - 'double complex' vice 'complex' in an example

11. Ballot resolution for SC22 N3219 (N1028, N1029, N1030) (Benito)

N1028 - C Locale, Narrative Cultural Specification (22 Sep 03)

N1029 - C Standard Locale

N1030 - Summary of Voting, LB on C Locale Registration with ISO/IEC 15897.

Ballot was APPROVED, (8,0,1,12), with comments from the Netherlands, and Sweden.

WG14 agreed to register the C locale in 1999. Got documented, sent to SC22 for ballot. Comments were initially sent to WG15 - where nothing happened. Got comments, but no resolution to comments. Has been open since then. Q: 1) do we still want to register the C locale, and 2) is it in the format wanted?

Registration gives us 'ownership' of the C locale.

TP prefers that the matter just get dropped, and the C locale

General consensus to proceed.

NM: Believes registration serves no purpose.

KS: Other registrations are in process, but the process takes time.

NM: No one is using these - others are creating their own locales. Although registrations are being worked on, nobody cares, and the registrations will never happen.

ACTION: Convener to prepare a Disposition of Comments and forward to SC22 for action.

12. Defect Reports (Wednesday)

"R => C" : Changed from Review to Closed.

New DR from INCITS, presented by Randy Myers, DR-294, on the formal model for restrict.

DR-285 - R => C

DR-288 (N1012) - deficiency on multibyte conversions. More time is needed to assess the impact on the char32 work? Not really a 'defect', but a 'deficiency'. OPEN

DR-289 (N1015) Function prototype with [restrict], The Open Group Agreed as needed.

ACTION: LJ to propose suggested changes to DR-289 (on WiKi). CLOSED - see dr_289.htm

DR-292 (N1025) variable -> object (as applicable) Discussion on the meanings of the Standard's use of the term 'variable', and how it differs, conceptually, from 'object'. Can't just search and destroy, i.e. not all of the proposed changes are applicable. Cannot declare objects, so any discussion involving declaration have to be either identifiers or variables.

DG - The Standard defines 'objects' as having a region of storage

Most rejected, some accepted. SEE dr_292_edits.htm.

Note, "leave as is" means 'leave the C Standard as it is', i.e. the proposed TC was rejected.

DR-291 (N1024) - INEXACT FP Exceptions (Plauger)

MC suggested looking at the revised version of 754 w/r/t the use if the inexact flag. PJP walked through the submittal, leading a discussion on the specific changes being proposed. FT, MC, DG, DK pointed out a number of inconsistencies w/ 754 requirements and the proposed changes.

ACTION: PJP to draft the response for his proposal to DR-291 for review in Coogee. FT volunteered to review the response.

DR-290 (N1017) (Tydeman) - FLT_EVAL_METHOD extra precision and/or range

Descriptions of assignment and cast contradicts the description of FLT_EVAL_METHOD. Return, argument passing, and register variable may also contradict FLT_EVAL_METHOD. First two items accepted, last two items rejected. See dr_290_edits.htm

DR-282 R => C - edit change.

1st paragraph, change "member was omitted" to "member were omitted"

DR-274 R => C - fix 'report' (i.e. the 'link' from the prior DR)

DR-272 R => C

DR-268 LJ Proposed new wording - accepted.

ACTION: LJ to provide words to secty. DONE- SEE dr_268_words.htm

DR-261 needs more thought - keep in Review

DR-251 Mis-marked as Review ??? Accept the suggested TC

DR-230 R => C

DR-287

DG - flags are not objects, thus the constraint on modifying objects does not apply to flags. Reject 1st paragraph in Suggested TC. Make 2nd paragraph a RoR. Add footnote.

ACTION: DK, footnote words - DONE (see below)

Response:

---------

As noted in the response to DR 087, function calls in the same

expression do not overlap. This has not changed in C99.

Technical Corrigendum:

----------------------

Add a footnote to 6.5 Expressions, paragraph 2, after the first

sentence: A floating-point status flag is not an object and may be

set more than once within an expression.

Add a footnote to 7.6 Floating-point environment, paragraph 1, after

the third sentence: A floating-point status flag is not an object and

be set more than once within an expression.

DR-286

Multiple terminology, meaning the same thing? Need to pass this by Jim Thomas, who wrote most of these words, to see if there was some rationale for their use / differentiation. In general, the proposed TC is acceptable.

DR-284 - CLOSED

math.h does NOT define INT_MIN, or INT_MAX

ACTION: PJP to provide RoR words - DR-284 DONE

Proposed Response:

No library header includes another library header. The header <math.h> does not define INT_MIN or INT_MAX. A program that wants to check the return value for equality with one of these macros must include <limits.h>.

DR-266

RM position is sizeof never overflows. DG - ignore the calloc problem. PJ - size_t must be representable, cannot overflow, by definition. Attempt to overflow s/be a constraint violation / undefined behavior.

ACTION: DK, RoR DR-266 - DONE (see below)

Response:

---------

The program is not strictly conforming because it exceeds an

environmental limit. If the implementation generates code, there is

no requirement for a diagnostic. In the event that sizeof is called on

the object, a diagnostic should be issued, but is not required.

DR-260

Previously thought to be closed in Santa Cruz, then readdressed in Oxford.

DG - response to Q1 does not seem to be right. PJ-what commercial import does this DR have. Not proposing a TC.

ACTION: FG to rephrase RoR, DR 260.

DR-236 - type base aliasing rule

RM, DG, PJ generally agreeing on concept - words a problem.

ACTION: DG to develop words, RoR, DR-236, restricting use of union members.

need to address malloc storage as well??

13. Separate WG14 administration and J11/U.S. TAG meetings

See US WG14TAG minutes following these minutes.

14. Proposed Addition of Special Math Functions - N1023 (Plauger)

WG21 planning on adding a number of math functions to a TR (Library Extensions). This is a proposal to add the same functions to C, for compatibility purposes, in a Type 2 TR, and work in close liaison with C++ to insure comp ability.

Two interest items: 1) add a lot of 'special' math functions & 2) reconciliation of C++ libraries with C99. All of the 'special' math functions are writeable in C. PJ willing to do the 'grunt' work.

DG - generally supportive. Possible namespace issues for using math.h, concerned about requirements on accuracies, tricky functions to get accurate. Believes there is a real need to standardize the functions presented.

PJ - agrees, sees making use of 'relative' error and ranges for 'absolute' errors.

DW - same potential namespace collisions in math.h, would also like to see some PD reference implementations - sees implementation as difficult.

FG - would these by type generic (PJ-yes), TR should have an informative section that explains "why" we are taking on this work (PJ-agree).

No voicing of opposition to the proposal. Francis predicts that UK will oppose the project - but he could be wrong.

Straw poll of NBs indicate favor of supporting the proposal. Convener will develop a NWI for a Type 2 TR, to be coordinated with the effort underway in WG21.

ACTION: WG14 Convener to begin development of a NWI for a type 2 TR for addition of Special Math Functions, to be done in close coordination with WG21.

15. Internationalization APIs - N1027 (Keld) (Fri-AM)

JTC1 killed this standards project due to lack of progress, but suggested it could be revised as a TR. Keld has brought it to WG14 as a proposed TR. Keld gave a presentation on the salient points of the architecture.

Some of these items have the same name as POSIX APIs, but are not compatible with them. Others don't exist in either C or POSIX.

NM sees a number of issues that are not addressed by the proposed document, and there are a number of other players that should participate in such an effort. Without their participation, there is no point in doing the work.

KS pointed out that this is a personal contribution, not something from WG20.

TP believes this is a bad idea, but suggested that HODs go back and discuss with their NBs for feedback.

Straw poll of NBs showed either no, or undetermined, interest at this time.

No consensus for immediate action, but may revisit later.

16. I18N Functionality as listed by WG20 (Keld)