Security TR Editor's Report

State of Document

N1078 is a mixture of specific edits requested by the committee at the last meeting and edits discussed in principle at the last meeting.

In general, changes to the document are marked with change bars in the margin. However, the change bars are not perfect due to limitations of the tools used to produce the document (or the workman using them). Sometimes the last line of a changed multiline change will not be marked. Sometimes an extra change bar will appear on an unchanged line above or below a changed line. Some new footnotes do not have change bars.

The following changes are not in this draft:

The description of the rand_s function has not been updated with the requirements making it suitable for cryptography.
The Annex listing secure functions that should be used in preference to insecure functions is missing.
The Rationale is missing.

All subclause numbers in this report refer to N1078.

Major Changes

This section summarizes changes that potentially effect anyone attempting to implement a secure library based on the last draft.

Macros

__USE_SECURE_LIB__ is now __STDC_WANT_SECURE_LIB__.
__GOT_SECURE_LIB__ is now __STDC_SECURE_LIB__.

Note that the Sydney Minutes left off the two trailing underscores in places. However, my meeting notes and the pattern of other macros in C99 calls for two trailing underscores. Thus, N1078 uses the two trailing underscores.

As was agreed at Sydney, __STDC_SECURE_LIB__ is predefined rather than being defined in the various headers.

The value of __STDC_SECURE_LIB__ was increased to match the date of this draft.

As was discussed at Sydney, if __STDC_WANT_SECURE_LIB__ is defined to be 0, then none of the new names in the TR are defined by their headers.

If __STDC_WANT_SECURE_LIB__ is defined to be 1, then the new names in the TR are defined by their headers.

If __STDC_WANT_SECURE_LIB__ is undefined, then it is implementation-defined whether the new names are defined by their headers.

Null pointer support

The following functions were modified to not copy anything and to return ERANGE if either the source or destination pointer was NULL:

memcpy_s
memmove_s
strcpy_s
strncpy_s
strcat_s
strncat_s
wcscpy_s
wcsncpy_s
wmemcpy_s
wmemmove_s
wcscat_s
wcsncat_s

The strnlen_s and wcsnlen_s functions return zero if passed a null pointer.

The gets_s function performs no input if the pointer to store the result is null. In that case a null pointer is returned.

The qsort_s and bsearch_s functions allow the array to be a null pointer if the number of elements in the array is zero.

Issue: Did we go too far in specifying the behavior for null pointers? Microsoft is carefully validating all function parameters, and calls a user written trap handler if a function has parameters with erroneous values. The Microsoft approach allows the programmer to control whether the program will automatically halt or recover if a bad parameter is seen. Do we really want to define such features away?

scanf functions

As was proposed by Plauger at Sydney, the scanf-family functions now allow an optional precision for the c, s, and [ conversion specifiers. The precision gives the number of elements in the array in which the result is to be stored.

It is undefined behavior if a precision is given for any other conversion specifier. This is consistent with precision in printf-family functions.

The default precision for the old scanf-family functions is (size_t) -1, which implies all arrays are big enough to hold the result. The default precision for the new _s scanf-family functions is (size_t) 0, which in effect requires the programmer explicitly to provide a precision to avoid the conversion failing.

Issue: Should the default precision for fscanf_s really be .0, or should it be .*? The .* is more consistent with previous drafts, and means that format strings need not be edited when converting from fprintf to fprintf_s, as long as the array sizes are provided in the parameter lists.

Issue: I've gotten some pushback on the argument giving a precision value for a .* precision occurs before the destination of the conversion specification. The ordering in the TR is consistent with printf, but for those who have grown use to the previous approach, the order looks backwards.

Function Name Changes

Old Name	New Name
strnlen	strnlen_s
wcsnlen	wcsnlen_s
gmtime_r	gmtime_s
localtime_r	localtime_s
strtok_r	strtok_s

getenv_s

The getenv_s function now sets needed to the number of characters needed to store the result including the trailing null character (previously, the null character was not included in the count).

asctime_s

The asctime_s function's algorithm now uses mktime() to normalize its time argument.

The year is now saturated at 9999.