- 15 April 2008: 09:00 to 12:00 and 13:30 to 17:00
- 16 April 2008: 09:00 to 12:00 and 13:30 to 17:00
- 17 April 2008: 09:00 to 12:00
The MITRE Corporation
2280 Historic Decatur Road
Suite 100
San Diego, CA 92106
+1 619.758.6002
- INCITS
- USA
James Moore, James dot W dot Moore at IEEE dot org
1.1 Opening Comments (Moore, Benito)
Jim Moore welcomed everyone to the meeting and described the arrangements.
1.2 Introduction of Participants/Roll Call
- Convener: John Benito
- US: Jim Moore (HOD), Tom Plum, Larry Wagoner, Robert Karlin, David Melski
- UK: Clive Pygott (by telephone)
- Canada: Steve Michell (by telephone)
1.3 Procedures for this Meeting (Benito)
The convener reviewed the usual meeting procedures, notably that the working group makes decisions via consensus, not voting.
1.4 Approval of previous Minutes [N0153] (Moore)
The minutes were approved with no additional comments.
1.5 Review of previous actions items and resolutions, Action Item and Decision Logs (html, xls)
The group reviewed open action items and updated the status of a few.
1.6 Approval of Agenda
The group approved the agenda.
1.7 Information on Future Meetings
1.7.1 Future Meeting Schedule
1.7.1.1 Meeting #11, 13-15 July 2009, Ottawa or Toronto, Canada, SCC
There was a suggestion that WG23 should colocate with an Open Group meeting that is scheduled for July in Toronto. After discussion, it was decided that the dates will remain the same and the location will be Ottawa. Participants may make individual arrangements to attend both meetings if they so choose.
1.7.1.2 Meeting #12, 02-04 September 2009, Delft, Netherlands, NNI
The convener explained that the meeting will be hosted by NNI and ACE. We will start during the final half-day of the SC 22 plenary. Michell requests that there should be telecon capability for this meeting.
1.7.1.3 Other meetings
It was suggested that it might be appropriate to have a December 2009 meeting but no firm decision has yet been made. Tullio Vardanega has informed that convener that Italy would like to host WG23 again. WG14 is meeting in Italy during April. The convener would like to arrange those meetings in consecutive weeks. Clive Pygott offers to host a meeting in the UK during 2010. Canada may host the SC22 plenary meeting in September 2010. We would want to colocate with them.
We decide that our next ballot will be a PDTR ballot and will commence as soon as the editor can prepare the draft. Meeting #11 will be concerned with language annexes, marketing plans and other issues. The editor will call meetings of the editorial team as needed.
[ACTION #10-01] Convener and secretary: Update the schedule in [N0167] and reissue as [N0183].
1.7.2 Future Agenda Items
[This item was in the agenda by mistake and will be removed from future agendas.]
1.7.3 Future Mailings
- Post meeting mailing - This was scheduled for 18 May.
- Pre meeting mailing - The group decides to discontinue the practice of pre-meeting mailings. Instead, the secretary should distribute reminders of action items.
2.1 SC 22
There has been no meeting of SC22 since the previous report.
2.2 PL22.3/WG5 (Fortran)
No report
2.3 PL22.4/WG4 (COBOL)
Robert Karlin reported that COBOL 2011 will go to FCD later this year. They are interested in doing a language-specific annex. The biggest problem is that no one from the US has stepped up to taking the job of convener.
2.4 WG9 (Ada)
Erhard Ploedereder reported that WG9 has scheduled a workshop for the Ada Europe conference on Sunday, June 7 to consider a language-specific annex. The WG 23 convener will attend.
2.5 PL22.11/WG14 (C)
Tom Plum reported that this group met recently in Markham, Ontario, Canada. The C standard currently refers to TR 24731-1 for information regarding bounds checking. The equivalent material has been incorporated into the next draft of the C standard as a normative option.
2.6 J16/WG21 (C++)
Tom Plum reported that this group recently met in Summit, NJ and is processing NB comments on its first CD ballot.
2.7 ECMA TC39/TG2 (C#)
Tom Plum reported that TC39 has reorganized. Its only remaining activity is ECMAScript. The liaison designation should be changed to "ECMA TC39 (ECMAScript)." C# and CLI have gone to a new TC49/TG2 (C#). Tom is willing to continue as the liaison to TC49. Tom has asked TC39 to designate a liaison to WG23 and thought that they had done so. This is an important group because many of the major players are involved, dealing with security at the web-site scripting level.
2.8 MISRA (C)
No report.
2.9 MISRA (C++)
Clive Pygott reported that there is little current activity. The circulation of the MISRA C++ standard is about a year old, but too little comment has been received to merit holding a meeting yet.
2.10 SPARK
No report.
2.11 MDC (MUMPS)
No report.
2.12 SC7/WG19 (UML)
No report.
2.13 Other Liaison Activities or National body reports
No report.
3.1 Editor's draft of PDTR 24772 (N0170)
This document was circulated for PDTR ballot and was approved with only the UK casting a negative ballot. Comments received during balloting were considered under agenda item 3.3.
3.2 Review of Editorial Meetings
3.2.1 Report of Editors' Meeting, 12 December 2008 (N0172)
3.2.2 Report of Editors' Meeting, 28 January 2009 (N0173)
3.2.3 Report of Editors' Meeting, 18 February 2009 (N0175) and (N0177)
The convener summarized the editors' meetings and introduced the four descriptions (N0177) proposed by the editors for inclusion in the technical report. The working group reviewed the proposals and made minor changes to them with the results recorded in (N0182). It was decided to include these descriptions, as amended, in the next draft of the technical report.
[ACTION #10-03] Editor: Incorporate [N0182] in the next draft of 24772.
3.3 Review and resolve Ballot comments
3.3.1 Collated NB comments: (N0176a, doc, and n0176b, xls)
The meeting began reviewing the results of the ballot on PDTR 24772. Work began with a review of the technical National Body comments contained in (N0176b); disposition were recorded in (N0180). The editor will disposition the editorial comments.
Robert Karlin agreed to consider writing replacement text for sub-clause 5.2 in consideration of comment UK-37. Overnight, he provided (N0185) which was revised by the group as (N0186) and accepted for inclusion in the next draft of the technical report.
Clive Pygott provided text overnight to address FR-34. It was accepted as shown below:
6.25.5 - 2nd bullet
ensuring that, for each instantiating type, a generic is entirely valid (including any parts which are not used in the current program, and so may not be reported as a compiler-time error)
Clive Pygott provided text overnight to address CA-18. It was accepted as shown below:
6.12.1
Interfacing with hardware, other systems and protocols often requires access to one or more bits in a single computer word, or access to bit fields that may cross computer words for the machine in question. Mistakes can be made as to what bits are to be accessed because of the "endianness" of the processor (see below) or because of miscalculations. Access to those specific bits may affect surrounding bits in ways that compromise their integrity. This can result in the wrong information being read from hardware, incorrect data or commands being given, or information being mangled, which can result in arbitrary effects on components attached to the system.
Tom Plum agreed to consider writing a revised disposition to CA-4. After study, he decided that no change to the disposition was needed.
Tom Plum and Robert Karlin collaborated to produced text overnight to address CA-26. It was accepted as shown below:
In some languages a signed integer can be converted to an unsigned integer without any range-checking. Thus, a negative signed integer value converts to a very large positive unsigned integer value. When the programmer passes a negative value as the object size when allocating space for an object, the result may be an extremely large object, or may cause the allocation to fail. Some languages such as COBOL have features that limit the number of significant digits in an integer data item, though this only prevents overflow and allocation failure, not invalid results. In other languages, such as C, similar restrictions can be imposed through semantic conventions and enforced by library functions. The C technical report ISO/IEC TR 24731-1 [8] defines (via typedef)an unsigned integer type (rsize_t) that should be restricted to be less than an enforceable maximum object size (RSIZE_MAX), allowing both the caller and the called function to validate that the size used to allocate space for an object is within reasonable limits. Steve Michell agreed to consult a past version of CLL and recreate text that appears to have been lost. This would address CA-47 and JP-67. After discussion, Steve's text was revised and accepted as shown below:
x.1 Description of application vulnerability
Many programming languages provide a construct, (switch statement in C-based languages, case statement in Pascal-based languages), that chooses among multiple alternative control flows based upon the evaluated result of an expression. The use of such constructs may introduce application vulnerabilities if not all possible cases appear within the switch or if control unexpectedly flows from one alternative to another.
We will use the terminology "chooser" for the expression that evaluates the expression and selects alternatives, and "choice handler" for the code that is executed for each choice made by the chooser expression. Multiple selections from the chooser can have the same choice handler. There may also be a "default choice handler" for any choices made by the chooser that do not have an explicit choice handler.
X.3 Mechanism of Failure
Having incomplete coverage of choice handlers available from the chooser can result in unexpected branching, if there is no default choice handler available. Some implementations of such conditionals may be computed branches while others may be equivalent to chained if-then-elsif-else statements. Computed transfers have more risk of reaching arbitrary codeHaving incomplete coverage of the choices available from the selection, as well as a default to trap results in all non-programmed branches taking that default, which may be contrary to a programmer's expectation, especially if the selection set has been expanded (say due to adding new items). A default choice handler undermines static coverage analysis by forcing a possibly false postive.
Some languages permit a choice executing one case to fall through to the next case if a "condition termination" (such as continue) is not used. This permits more flexibility in reducing code but a mistakenly omitted condition termination statement can result in unexpected code execution.
Using an enumerable type, especially if the language enforces 100% coverage of the type by choice handlers, guarantees that all choices have a handler.
Larry Wagoner provided text overnight to address UK-73. It was accepted as shown below:
7.3.4 Software developers can avoid the vulnerability or mitigate its ill effects in the following ways:
*Libraries should come from a trusted source with a digital signature.
*If the library does not come from a trusted source, the source code of the library should be reviewed and then the library should be built from the reviewed source before using it. Libraries that are not from a trusted source and for which the source code is unavailable should not be used as it is very difficult to determine what these libraries actually do, and the potential for malicious code is high.
*All input to libraries should be validated for content and length to prevent buffer overflows and other problems.[ACTION #10-02] Editor: Complete the disposition of comments in [N0180] to create [N0184]
3.3.2 Liaison comments from SC 22/WG 9 on PDTR 24774 (N0174)
It was noted that many of the WG9 comments were also submitted as NB comments. Steve Michell created a cross-reference of WG9 comments that were duplicated by NB comments, hence allowing us to avoid the workload of reexamining each one individually. In the comment disposition, duplicated comments are marked in the form of "See CA-19", indicating that the comment duplicates national body comment CA-19 and has the same disposition.
The meeting continues by considering technical and general comments in [N0174] that are not duplicated by NB comments. The disposition created during the meeting is document [N0181].
Some of the comments suggest work in areas that the working group had previously decided to defer in order to focus its resources. It was decided that the list of deferred areas should be documented.
[ACTION #10-04] Jim Moore: Create a list of issues that may be considered for a future revision. Include the following in the list: object-orientation, concurrency, scripting languages, and, possibly, additional material regarding floating-point arithmetic. Reference document [N0181], BE-05.
The number and substance of the comments on Clause 5 suggest that major revision might be appropriate.
[ACTION #10-05] Erhard Ploedereder, Larry Wagoner; Perform an overall reconsideration of the content of Clause 5 and recommend actions to improve. Consider document [N0181], notably the general and technical comments by Belgium made on Clause 5 and its sub-clauses.
Comments that were made on subclause 6.26 suggested that a rewrite might be advisable.
[ACTION #10-06] Robert Karlin: Look at the German comments on 6.26 that are contained in [N0181] and propose appropriate changes or rewrites.
Editorial comments were referred to the editor for disposition.
[ACTION #10-07] John Benito: Complete the disposition of comments in [N0181] to create [N0187].
3.4 Language specific annexes
WG23 has not received any drafts of language-specific annexes. The convener has been advised that a June workshop led by WG9 will produce a draft annex to be considered at our Meeting #11. It is hoped that Fortran will provide a draft annex also. It is hoped that one of the participants in WG23 will provide a draft annex for the C language.
Larry Wagoner explained that we need a plan to make people acquainted with the good work that will be included in the Technical Report. This will be placed on the agenda of the next meeting.
5.1 Review of Decisions Reached
5.2 Review of Action Items
5.3 Thanks to Host