ISO/ IEC JTC1/SC22/WG14 N1112

Document: N1112						Date: 2005/03/21


Programming languages, their environments and system software interfaces

Secretariat:  U.S.A.  (ANSI)


ISO/IEC JTC 1/SC22 N3880



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






SC 22 Secretariat






Summary of Voting






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:












SC 22 N3838





Sally Seitz


25 West 43rd Street

New York, NY  10036

Telephone:  (212) 642-4918

Fax:             (212) 840-2298



_____end of cover page, beginning of PDTR registration summary______________




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



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



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



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.



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


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)



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.



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, 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: Consider adding: "and the other elements of /s/ are unspecified".


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


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

How does it indicate failure?


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


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


Page 31: 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: 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: 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: 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



     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


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").