From owner-sc22docs@open-std.org Thu Mar 24 14:42:10 2005 Return-Path: X-Original-To: sc22docs-domo Delivered-To: sc22docs-domo@open-std.org Received: by open-std.org (Postfix, from userid 521) id 71935EF75; Thu, 24 Mar 2005 14:42:10 +0100 (CET) X-Original-To: sc22info@open-std.org Delivered-To: sc22docs@open-std.org Received: from email1.ansi.org (outbound.ansi.org [12.15.192.5]) by open-std.org (Postfix) with ESMTP id A7D9BEF73 for ; Thu, 24 Mar 2005 14:42:06 +0100 (CET) Received: by rpb2.nycrnybb.ispnetinc.net with Internet Mail Service (5.5.2653.19) id <19J1WMF0>; Thu, 24 Mar 2005 08:40:08 -0500 Message-ID: From: Sally Seitz To: sc22info@open-std.org Subject: FW: N 3880-Summary of Voting on SC 22 N 3838, Registration for W DTR 24731-Information technology-Programming languages, their environment s and system software interfaces-Specification for Secure C Library Funct ions Date: Thu, 24 Mar 2005 08:40:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C53076.FAC732C0" Sender: owner-sc22docs@open-std.org Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C53076.FAC732C0 Content-Type: text/plain Please disregard earlier email. The document location was not included. My apologies ISO/IEC JTC 1/SC22 Programming languages, their environments and system software interfaces Secretariat: U.S.A. (ANSI) ISO/IEC JTC 1/SC22 N3880 TITLE: Summary of Voting on SC 22 N 3838, Registration for WDTR 24731-Information technology-Programming languages, their environments and system software interfaces-Specification for Secure C Library Functions DATE ASSIGNED: 2005-03-24 SOURCE: SC 22 Secretariat BACKWARD POINTER: N/A DOCUMENT TYPE: Summary of Voting PROJECT NUMBER: 22.24731 STATUS: The results of this ballot are forwarded to SC 22/WG 14 for review, production of a disposition of comments report, and preparation of the DTR text. The comments of the United Kingdom can be found at: http://www.open-std.org/jtc1/sc22/def/n3880.pdf ACTION IDENTIFIER: ACT DUE DATE: N/A DISTRIBUTION: Text CROSS REFERENCE: SC 22 N3838 DISTRIBUTION FORM: Def Sally Seitz ANSI 25 West 43rd Street New York, NY 10036 Telephone: (212) 642-4918 Fax: (212) 840-2298 Email: sseitz@ansi.org _____end of cover page, beginning of PDTR registration summary______________ SUMMARY OF VOTING ON Letter Ballot Reference No: SC22 N3838 Circulated by: JTC 1/SC22 Circulation Date: 2004-12-14 Closing Date: 2005-03-14 SUBJECT: Summary of Voting on SC 22 N 3838, Registration for WDTR 24731-Information technology-Programming languages, their environments and system software interfaces-Specification for Secure C Library Functions The following responses have been received on the subject of registration: "P" Members supporting registration without comments 6(Czech Republic, Denmark, Finland, France, Italy, Republic of Korea) P" Members supporting registration with comments 3 (Germany, Netherlands, United States) "P" Members not supporting registration 2(Canada, Japan) "P" Members abstaining 2 (Switzerland, United Kingdom) "P" Members not voting 7 (Belgium, China, Egypt, DPR of Korea, Romania, Russian Federation, Slovenia, Ukraine) National Body Comments Canada Comments on WDTR 24731 "Specification of Secure C Library Functions" Canada does not agree with the use of the word "secure" in the title of this document. This word carries considerable baggage for the safety and security communities and implies functionality that is not provided. We would suggest alternative terminology, such as "bounded". Some of the functions provided exist or conflict with functions provided in other domains, such as POSIX or SUS. If the behaviour is different than these specifications, then programs that attempt to use them may be incorrect. Even if the behaviour is the same, then the pre-existing specification must be respected. Examples of such functions are: strtok_r, strcpy_s and strcat_s. In particular, strcpy_s provides identical functionality to strlcpy which has been in use for some time. Special mention is required of strerror_s. A mechanism is required to predetermine the size of the string to be returned so that the buffer can be preallocated. Special mention is also made or "rand". Saying that cryptography methods must be used is insufficient. The function specification ignores several issues, such as blocking, enthropy and seeding of such functions. Special mention is made of strtok_r. This function should clearly state that any string to be read by such a function may already be effectively unbounded, and while it may be bounded by the buffer in strtok_s, the effects of inputting the original unbounded string may already have occured. Germany German Comment on document ISO/IEC JTC 1/SC 22 N3838 ISO/IEC WDTR 24731 Information technology-Programming languages, their environments and system software interfaces-Specification for Secure C Library Functions: 1) sprintf_s and other read functions with the exception of strnlen need to be addressed somehow. 2) it is worth to consider, whether strncpy_s and strncat_s variants with one parameter for length should be added. Zero-termination is in that case assumed. 3) it is worth to consider offering a feature, simply aborting the program upon buffer length overrun. Such an option could be activated conditionally via #pragma or #define. (End of comment) Japan As already described in our comment on NWIP ballot, we think it is extremely hard to make the C programming language secure by just adding a set of new functions leaving the existing insecure ones untouched. To make the C programming language truly secure it is necessary to abolish the existing insecure features like pointer operations and some dangerous functions. We strongly request WG14 to produce the rationale or annex which clearly states the following points: 1) Clearly state the policy and criteria for introduction of new functions For example, we think that gets_s() is redundant and should be eliminated from the TR because the functionality of gets_s() can be covered by existing fgets() function. So, please make clear the reason of adding gets_s() besides fgets(). 2) Clearly and concretely state what kinds of security hole exist in the current ISO C standard(syntax and libraries). 3) Clearly explain what kind of vulnerability is fixed for each proposed function one-by-one. For example, we cannot understand what is improved in wctomb_s() from the original wctomb(). Please provide the explanation of the advantage of wctomb_s() over wctomb(). 4) Give the guide for secure programming by using the proposed functions. Netherlands The Netherlands votes 'yes' on the Registration of WDTR 24731 with the following comments: 1 - Section 3.1, the definition of the term 'diagnosed undefined behavior' is unclear; change to behavior, that is invoked by the use of a nonportable or erroneous program construct or of erroneous data,and that an implementation shall diagnose by, in effect, calling an implementation-defined function. 2 - Section 5.3, para 2; replace 2nd sentence by If a function that has parameters of type rsize_t is called with values for those parameters that are greater than RSIZE_MAX the behaviour shall be diagnosed undefined behaviour. 3 - Section 5.3, para 4, last sentence: replace 'diagnosable' by 'diagnosed'. 4 - Section 5.5.2.1, para 5, first sentence: replace 'diagnosable' by 'diagnosed'. United States Set 1: 1. WG14/N1089 is a good start on a rationale. There should be one, either included in the TR or in a separate document. 2. The rationale should discuss why there are not _s versions of the following functions, and the general philosophy involving minimizing performance impact. strchr, strcspn, strpbrk, strrchr, strspn, strstr 3. The following functions are missing the specification that they open a file for exclusive access. tmpfile_s, fopen_s, freopen_s 4. From the editor's report, it appears that sprintf_s and snprintf_s will do essentially if not exactly the same thing. Maybe only one of them is needed. 5. It would be best for the committee to spend some more time discussing the notion of diagnosed undefined behavior. This is a new invention for the C standard. ########## Set 2: Page numbers refer to within the document, not the PDF page number. Page v: End of paragraph 6: Extra(?) "*". Page 1: Should ISO/IEC 9899:1999/Cor 2:2004 be added to list of references? Page 7+: Consider changing "bug" to "programming error". Page 7: Footnote 9: Consider changing "constant expression" to "integer constant expression". Page 13: Paragraph 7 / Example 2: The end of that example says: "No assignment to /s/ occurs.". Where is that requirement in normative text? Also, this seems like a large burden to place on the implementation (requires a temporary buffer to hold the input string until that string's length is known). Better would be s[0] is set to a null character, and the other elements of /s/ are unspecified. Page 14/15: Footnote 13: Is on wrong page and overlays the section number. Can the same footnote be referenced by three different sections (which are on different pages)? Page 16: 5.4.4.1p4: Consider adding: "and the other elements of /s/ are unspecified". Page 17: 5.5.1.1p2: Consider adding: "maxsize == 0" to the list of diagnosed undefined behavior. Page 20: 5.5.2.2: Why does qsort_s return void instead of errno_t? How does it indicate failure? Page 24: 5.6.1.2: End of paragraph 3: Extra(?) "*". Page 28: 5.6.2.2p4: The 'm' in 'm+n' should be italic. Page 31: 5.6.4.1p5: Why are there three '.' characters used to overwrite the end of the string (Answer could go in a footnote)? Would it be useful to show some examples both with and without the overwrite? Page 33: 5.7.2.1p2: Is the broken down time before or after the 1900 has been added to it? Why 0 rather than -999 (which fits in a 4 digit field)? Page 37: 5.8.1.1: What happens if the string is longer than the space to store it? Is the first character set to null character? Page 38: Footnote 28 extends too far down the page. Pages 39-40: Footnote 29 is referenced from two pages. Page 46: 5.8.2.2.2p4: The 'm' in '-m+n' should be italic. ########## Set 3: 1. The TR leaves it up to the implementation to determine the value of RSIZE_MAX. The most useful value will often depend on both the implementation and the application, so many/most implementations will provide a way for an application to specify the value (at run-time). On the other hand, some implementations may choose to make the value an unalterable translation-time constant. We would like to see a specified means to set the value of RSIZE_MAX, with a status return indicating whether or not the value was successfully set. One thought might be to do this through a function-like macro in stdint.h, e.g. "errno_t SET_RSIZE_MAX(size_t)". An implementation that did not support an application's setting the value at run-time would not define the macro. Otherwise, an invocation of the macro would return zero if the value was successfully set, or a non-zero value to indicate failure (e.g. an inappropriate value was specified or the application was built in a way to disallow run-time modification of the value). 2. The definition of diagnosed undefined behavior as calling an implementation defined function might benefit from examples of the name ans signature of such a function - not as a requirement, simply to encourage more than one implementation to make the same choices. 3. The memcpy_s function does not list overlap between input and output among its diagnosed undefined behaviors. Is that solely because the language does not define pointer comparison between distinct objects, or is it considered a practical difficulty for real implementations? In fact, the wording of "take on unspecified values", seems to preclude overlap from being diagnosed. That's puzzling, as diagnosing memcpy calls that ought to be memmove calls is certainly a useful capability. ########## Set 4: 1. In some cases there seems to be change for the sake of it from what is either already standard or defacto standard. The common change seems to be return values that were char* with error being NULL being changed to this new errno_t type which is really just an int. strcpy_s strlcpy strcat_s strlcat asctime_s asctime_r gtime_s gtime_r localtime_s localtime_r 2. For many of the functions defined in this TR, it appears that very similar or identical alternatives are already available. In those cases, I'm not sure it makes sense to ignore prior art by defining new replacements. Some examples: A. tmpfile_s() is identical to the existing tmpfile() except for the style of returning the resulting FILE *. B. tmpnam_s() is almost the same as the existing tmpnam_r() except it includes an argument for the size of the destination buffer. More important, however, is the fact that it is still unsafe due to race conditions with others who might create the same files. Safe usage requires the use of tmpfile() or mkstemp() instead. C. strcpy_s() is equivalent to strlcpy(). It seems like providing yet another safe version of strcpy() would be confusing at best. D. fscanf_s() and related variants are just like the current routines except they require a size parameter for buffers that hold the result of %c, %s, and %[ formats. That's very useful, but I believe this feature could be added to the existing scanf() family in a compatible way. What's needed is a format modifier to indicate that the size is specified by a parameter, like the * in printf() format strings. Since scanf() already uses * for assignment suppression, a different character would be needed, but one could choose any unused format character and remain compatible with the existing scanf() functions. 3. A comprehensive Rationale for the TR should be provided. 4. The issues (including missing features) raised in the Secure TR Editor's Report, SC22 WG14 N1089, should be addressed. N1089 is available at http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1089.pdf 5. The committee should consider adding the following functions described in N1089: fprintf_s, printf_s, snprintf_s, sprintf, vfprintf_s, vprintf_s, vsnprintf_s, vsprintf_s, fwprintf_s, swprintf_s, vfwprintf_s, vwprintf_s, wprintf_s, vswprintf_s, mbstowcs_s, wcstombs_s, mbsrtowcs_s, wcsrtombs_s, wcrtomb_s 6. The committee should consider adding support for optional truncation during string copy. See _TRUNCATE in N1089. 7. A footnote should be added explaining that the tmpfile_s, fopen_s, and freopen_s functions should open their files in a "safe" mode giving exclusive (non-shared) access. 8. The committee should carefully consider the issues around "diagnosed undefined behavior," including: A. the name of the term B. the model of behavior C. where the description of diagnosed undefined behavior should appear in a subclause specifying a function (in the "Description" section, in the "Returns" section, or in a new section labeled "Diagnosed Undefined Behavior"). Sally Seitz Program Manager ANSI 25 West 43rd Street New York, NY 10036 Phone: (212) 642-4918 Fax: (212) 840-2298 ------_=_NextPart_001_01C53076.FAC732C0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Please disregard earlier email.  The document location was = not included.  My apologies

 

ISO/IEC JTC = 1/SC22

Programming languages, their environments = and system software interfaces

Secretariat:  U.S.A.  = (ANSI)

 

ISO/IEC JTC 1/SC22 = N3880

 

TITLE:

Summary of Voting on SC 22 N 3838, = Registration for WDTR 24731-Information technology-Programming languages, their environments = and system software interfaces-Specification for Secure C Library = Functions

 

DATE ASSIGNED:

2005-03-24

 

SOURCE:

SC 22 Secretariat =

 

BACKWARD POINTER: =

N/A

 

DOCUMENT TYPE:

Summary of Voting =

 

PROJECT NUMBER: =

22.24731

 

STATUS:

The results of this ballot are forwarded to = SC 22/WG 14 for review, production of a disposition of comments report, and = preparation of the DTR text.  The comments of the United Kingdom can be = found at: http://www.open= -std.org/jtc1/sc22/def/n3880.pdf

 

ACTION IDENTIFIER: =

ACT

 

DUE DATE:

N/A

 

DISTRIBUTION:

Text

 

CROSS REFERENCE: =

SC 22 N3838

 

DISTRIBUTION FORM: =

Def

 

Sally = Seitz

ANSI

25 West 43rd = Street

New York, NY  10036

Telephone:  (212) 642-4918 =

Fax:          &n= bsp;  (212) 840-2298

Email:  sseitz@ansi.org =

 

_____end of cover page, beginning of PDTR registration summary______________

 

 

SUMMARY OF VOTING = ON

Letter Ballot Reference No:  SC22 = N3838

Circulated by:              =   JTC 1/SC22

Circulation Date:            2004-12-14

Closing = Date:           &= nbsp;     2005-03-14

SUBJECT:  Summary of Voting on SC 22 N = 3838, Registration for WDTR 24731-Information technology-Programming = languages, their environments and system software interfaces-Specification for Secure C = Library Functions

 

 

The following responses have been received = on the subject of registration:

"P" Members supporting = registration without comments

6(Czech Republic, Denmark, Finland, = France, Italy, Republic of Korea)<= /p>

P" Members supporting registration with comments          &nbs= p; 

3 (Germany, Netherlands, = United = States)

"P" Members not supporting = registration

2(Canada, Japan)

"P" Members abstaining          &n= bsp;       

2 (Switzerland, United = Kingdom)

"P" Members not voting           =        

7 (Belgium, China, = Egypt, DPR of Korea, Romania, = Russian Federation, = Slovenia, Ukraine)<= /font>

 

National Body = Comments

 

Canada

Comments on WDTR 24731 "Specification = of Secure C Library Functions"

 

Canada does not agree with the use of the word "secure" in the = title

of this document. This word carries = considerable baggage for the

safety and security communities and implies functionality that is

not provided. We would suggest alternative terminology, such as

"bounded".

 

Some of the functions provided exist or = conflict with functions

provided in other domains, such as POSIX or = SUS. If the behaviour is

different than these specifications, then = programs that attempt to use

them may be incorrect. Even if the behaviour = is the same, then the

pre-existing specification must be = respected.  Examples of such

functions are:

    strtok_r, strcpy_s and = strcat_s.

 

In particular, strcpy_s provides identical functionality to strlcpy

which has been in use for some = time.

 

Special mention is required of strerror_s. A mechanism is required to

predetermine the size of the string to be = returned so that the buffer

can be = preallocated.

 

Special mention is also made or = "rand". Saying that cryptography

methods must be used is insufficient. The = function specification

ignores several issues, such as blocking, = enthropy and seeding of such

functions.

 

Special mention is made of strtok_r. This = function should clearly

state that any string to be read by such a = function may already be

effectively unbounded, and while it may be = bounded by the buffer in

strtok_s, the effects of inputting the = original unbounded string may

already have = occured.

 

Germany

German Comment on document ISO/IEC JTC 1/SC = 22 N3838

ISO/IEC WDTR = 24731

Information technology-Programming = languages, their environments and system software interfaces-Specification for Secure C = Library Functions:

 

 

1) sprintf_s and other read functions with = the exception of strnlen need to be addressed = somehow.

 

2) it is worth to consider, whether = strncpy_s and strncat_s variants  with one parameter for length should be = added.  Zero-termination is in that case assumed. 

 

3) it is worth to consider offering a = feature, simply aborting the program upon buffer length overrun.  Such an = option could be activated conditionally via #pragma or #define. =

 

(End of = comment)

 

Japan

As already described in our comment on NWIP = ballot, we think it is extremely hard to make the C programming language secure = by just adding a set of new functions leaving the existing insecure ones = untouched. To make the C programming language truly secure it is necessary to abolish = the existing insecure features like pointer operations and some dangerous functions. We strongly request WG14 to produce the rationale or annex = which clearly states the following points:

1) Clearly state the policy and criteria for = introduction of new functions  For example, we think that gets_s() is redundant = and should be eliminated from the TR because the functionality of gets_s() = can be covered by existing fgets() function. So, please make clear the reason = of adding gets_s() besides fgets().

2) Clearly and concretely state what kinds = of security hole exist in the current ISO C standard(syntax and = libraries).

3) Clearly explain what kind of = vulnerability is fixed for each proposed function = one-by-one.

 For example, we cannot understand what = is improved in wctomb_s() from the original wctomb(). Please provide the explanation of the advantage of wctomb_s() over = wctomb().

4) Give the guide for secure programming by = using the proposed functions.

 

Netherlands

The Netherlands votes 'yes' on the Registration of WDTR 24731 with the following = comments:

 

1 - Section 3.1, the definition of the term 'diagnosed undefined behavior' is unclear; change to behavior, that is = invoked by the use of a nonportable or erroneous program construct or of = erroneous data,and that an implementation shall diagnose by, in effect, calling an implementation-defined function.

 

2 - Section 5.3, para 2; replace 2nd = sentence by If a function that has parameters of type rsize_t is called with values = for those parameters that are greater than RSIZE_MAX the behaviour shall be = diagnosed undefined behaviour.

 

3 - Section 5.3, para 4, last sentence: = replace 'diagnosable' by 'diagnosed'.

 

4 - Section 5.5.2.1, para 5, first sentence: = replace 'diagnosable' by 'diagnosed'.

 

United States

Set 1:

 

1.  WG14/N1089 is a good start on a rationale.  There should be one, either included in the TR or in a separate document.

 

2.  The rationale should discuss why = there are not _s versions of the following functions, and the general philosophy = involving minimizing performance impact.

 

strchr, strcspn, strpbrk, strrchr, strspn, = strstr

 

3.  The following functions are missing = the specification that they open a file for exclusive = access.

 

tmpfile_s, fopen_s, = freopen_s

 

4.  From the editor's report, it = appears that sprintf_s and snprintf_s will do essentially if not exactly the same thing.  Maybe only one of them is = needed.

 

5.  It would be best for the committee = to spend some more time discussing the notion of diagnosed undefined = behavior.  This is a new invention for the C = standard.

 

##########

 

Set 2:

 

Page numbers refer to within the document, = not the PDF page number.

 

Page v:  End of paragraph 6: Extra(?) "*".

 

Page 1: Should ISO/IEC 9899:1999/Cor 2:2004 = be added to list of references?

 

Page 7+: Consider changing "bug" = to "programming error".

 

Page 7: Footnote 9: Consider changing = "constant expression" to "integer constant expression".<= /span>

 

Page 13: Paragraph 7 / Example 2: The end of = that example says: "No assignment to /s/ occurs.".  Where is = that requirement in normative text?  Also, this seems like a large burden to place = on the implementation (requires a temporary buffer to hold the input string = until that string's length is known).  Better would be s[0] is set to a null character, and the other elements of /s/ are = unspecified.

 

Page 14/15: Footnote 13: Is on wrong page = and overlays the section number.  Can the same footnote be referenced = by three different sections (which are on different = pages)?

 

Page 16: 5.4.4.1p4: Consider adding: = "and the other elements of /s/ are = unspecified".

 

Page 17: 5.5.1.1p2:  Consider adding: "maxsize =3D=3D 0" to the list of diagnosed undefined = behavior.

 

Page 20: 5.5.2.2:  Why does qsort_s = return void instead of errno_t?

How does it indicate = failure?

 

Page 24: 5.6.1.2: End of paragraph 3: = Extra(?) "*".

 

Page 28: 5.6.2.2p4: The 'm' in 'm+n' should = be italic.

 

Page 31: 5.6.4.1p5: Why are there three '.' characters used to overwrite the end of the string (Answer could go in = a footnote)?

Would it be useful to show some examples = both with and without the overwrite?

 

Page 33: 5.7.2.1p2: Is the broken down time = before or after the 1900 has been added to it?  Why 0 rather than -999 = (which fits in a 4 digit field)?

 

Page 37: 5.8.1.1: What happens if the string = is longer than the space to store it?  Is the first character set to = null character?

 

Page 38: Footnote 28 extends too far down = the page.

 

Pages 39-40:  Footnote 29 is referenced = from two pages.

 

Page 46: 5.8.2.2.2p4: The 'm' in '-m+n' = should be italic.

 

##########

 

Set 3:

 

1. The TR leaves it up to the implementation = to determine the value

    of RSIZE_MAX.  The = most useful value will often depend on both the

    implementation and the application, so many/most implementations

    will provide a way for an application to specify the value (at

    run-time).  On the = other hand, some implementations may choose to

    make the value an = unalterable translation-time constant.  We would

    like to see a specified = means to set the value of RSIZE_MAX, with a

    status return indicating = whether or not the value was successfully

    set.  One thought = might be to do this through a function-like macro

    in stdint.h, e.g. = "errno_t SET_RSIZE_MAX(size_t)".  An

    implementation that did = not support an application's setting the

    value at run-time would = not define the macro.  Otherwise, an

    invocation of the macro = would return zero if the value was

    successfully set, or a = non-zero value to indicate failure (e.g. an

    inappropriate value was = specified or the application was built in a

    way to disallow run-time modification of the value).

 

2. The definition of diagnosed undefined = behavior as calling an

    implementation defined = function might benefit from examples of the

    name ans signature of = such a function - not as a requirement, simply

    to encourage more than = one implementation to make the same choices.

 

3. The memcpy_s function does not list = overlap between input and output

    among its diagnosed = undefined behaviors.  Is that solely because = the

    language does not define = pointer comparison between distinct

    objects, or is it = considered a practical difficulty for real

    implementations?  In = fact, the wording of "take on unspecified

    values", seems to = preclude overlap from being diagnosed.  That's

    puzzling, as diagnosing = memcpy calls that ought to be memmove calls

    is certainly a useful = capability.

 

##########

 

Set 4:

 

1.  In some cases there seems to be = change for the sake of it from what

     is either already = standard or defacto standard.

 

     The common change = seems to be return values that were char* with

     error being NULL = being changed to this new errno_t type which is

     really just an = int.

 

     strcpy_s        = strlcpy

     strcat_s        = strlcat

     asctime_s       = asctime_r

     gtime_s         gtime_r

     localtime_s     = localtime_r

 

2.  For many of the functions defined = in this TR, it appears that very

     similar or = identical alternatives are already available. In = those

     cases, I'm not sure = it makes sense to ignore prior art by = defining

     new replacements. = Some examples:

 

     A. tmpfile_s() is = identical to the existing tmpfile() except for

        = the style of returning the resulting FILE *.

 

     B. tmpnam_s() is = almost the same as the existing tmpnam_r() except

        = it includes an argument for the size of the destination = buffer.

        = More important, however, is the fact that it is still unsafe = due

        = to race conditions with others who might create the same = files.

        = Safe usage requires the use of tmpfile() or mkstemp() = instead.

 

     C. strcpy_s() is = equivalent to strlcpy(). It seems like providing

        = yet another safe version of strcpy() would be confusing = at

        = best.

 

     D. fscanf_s() and = related variants are just like the current

        = routines except they require a size parameter for buffers = that

     =    hold the result of %c, %s, and %[ formats. That's very = useful,

        = but I believe this feature could be added to the = existing

        = scanf() family in a compatible way. What's needed is a = format

        = modifier to indicate that the size is specified by a = parameter,

        = like the * in printf() format strings. Since scanf() = already

        = uses * for assignment suppression, a different character = would

        = be needed, but one could choose any unused format character = and

        = remain compatible with the existing scanf() = functions.

 

3.  A comprehensive Rationale for the = TR should be provided.

 

4.  The issues (including missing = features) raised in the Secure TR

     Editor's Report, = SC22 WG14 N1089, should be addressed.  N1089 is

     available = at

     http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1089.pdf

 

5.  The committee should consider = adding the following functions

     described in = N1089:

 

     fprintf_s, = printf_s, snprintf_s, sprintf, vfprintf_s, = vprintf_s,

     vsnprintf_s, = vsprintf_s, fwprintf_s, swprintf_s, vfwprintf_s,

     vwprintf_s, = wprintf_s, vswprintf_s, mbstowcs_s, wcstombs_s,

     mbsrtowcs_s, = wcsrtombs_s, wcrtomb_s

 

6.  The committee should consider = adding support for optional

     truncation during = string copy.  See  _TRUNCATE  in = N1089.

 

7.  A footnote should be added = explaining that the tmpfile_s, fopen_s,

     and freopen_s = functions should open their files in a "safe" = mode

     giving exclusive (non-shared) access.

 

8.  The committee should carefully = consider the issues around

     "diagnosed = undefined behavior," including:

   A.  the name of the = term

   B.  the model of = behavior

   C.  where the description = of diagnosed undefined behavior should

       appear = in a subclause specifying a function (in the

       "Description" section, in the "Returns" section, or = in a new

       section = labeled "Diagnosed Undefined Behavior").

 

 

 

 

 

 

 

Sally = Seitz

Program = Manager

ANSI

25 = West 43rd Street

New = York, NY 10036<= /p>

Phone: (212) 642-4918

Fax: (212) 840-2298

 

------_=_NextPart_001_01C53076.FAC732C0--