Disposition of comments for WDTR 24731
Document: WG14 N1114
Date: 2005/04/12
Committee Response:
The Committee agrees, and suggests "secure" be changed to "safer".
In particular,strtok_r
,strcpy_s
andstrcat_s
.
strcpy_s
provides identical
functionality to strlcpy
which has been in use
for some time.
Committee Response:
The Committee wants to deliver a complete package, not_s
for some_r
for others. The committee will develop an Annex or Rationale to describe all differences, and keep parallel functionality whenever possible. The library constraint option can and most likely will make these functions behavior inconsistent with functions defined in other Standards. Also see GB08.
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.
Committee Response:
See GB08.
Committee Response:
The Committee agrees.
Committee Response:
The WDTR 24731 did not contain this function.
sprintf_s
and other read functions with the
exception of strnlen
need to be addressed
somehow.
Committee Response:
TR 24731 has the goal of not producing unterminated strings or storing past the end of a buffer. Except for a few specialized cases, functions that take strings as input parameters trust that the string is null terminated. More Rationale for this will be added. Also see US04 and US30.
strncpy_s
and
strncat_s
variants with one parameter for
length should be added. Zero-termination is in that case
assumed.
Committee Response:
The reivew copy of WDTR 24731 contains astrcpy_s
andstrcat_s
, with a length parameter.
#pragma
or #define
.
Committee Response:
This will be addressed by the library constraint feature. See GB02.
Committee Response:
See CA01.
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()
.
Committee Response:
The Committee will generate a clear policy for the
inclusion of the function gets_s
in the
Rationale.
Committee Response:
The Rationale will be extended to cover these issues, and the introduction section will be expended.
wctomb_s()
from the original
wctomb()
. Please provide the explanation of
the advantage of wctomb_s()
over
wctomb()
.
Committee Response:
The Rationale will be extended to cover these issues, there will also be some code examples added to the TR to show the advantage these new functions provide.
Committee Response:
See JP03.
Committee Response:
The Committee agrees that this section was not clear. This entire behavior is being redone.
rsize_t
is called
with values for those parameters that are greater than
RSIZE_MAX
the behaviour shall be diagnosed
undefined behaviour.
Committee Response:
The Committee agrees, this sentence will be rewritten
Committee Response:
The Committee agrees, this behavior is being redone.
Committee Response:
The Committee agrees, this behavior is being redone.
__STDC_[WANT_]SECURE_LIB__
to
__STDC_[WANT_]CHECKING_LIB__
and change
_s
suffixes to _c
or
_r
as appropriate.RSIZE_MAX
). They do, however, provide
parameter checking and re-entrancy.
Committee Response:
See CA01. The Macro name will be changed to match the package.
Committee Response:
The Committee agrees. Also see NL01.
Committee Response:
The Committee does not agree with moving this footnote. The Rationale will be expended to cover the name space pollution issue.
errno_t
and rsize_t
typedefs with
some other notational mechanism.Committee Response:
The Committee does not agree. Precedence exists in ISO standards (C++ and POSIX) to give meaningful names to types. This is common good programming practice.
compar ==
NULL
.Committee Response:
The Committee agrees.
mbrtowc
and
wcrtomb
. If these latter have a problem, fix
it rather than creating alternatives.
Committee Response:
The Committee does not agree. These functions have problems; the new functions will provide a safer approach. Conversion to the new functions will be more mechanical.
strcpy_s
, strncpy_s
,
strcat_s
, strncat_s
,
wcscpy_s
, wcsncpy_s
,
wcscat_s
, and wcsncat_s
functions
should all explicitly guarantee that s1
is
left null-terminated after the call, provided of course
that (s1 != NULL && s1max > 0 &&
s1max < RSIZE_MAX)
.Committee Response:
WDTR 24731 provides this functionality.
strtok_s
function needs an
s1max
parameter with appropriate tests on
s1
and s2
. I am agnostic as to
whether an s2max
is needed.Committee Response:
The Committee agrees. s2
does not need to
have a length associated.
Committee Response:
The Committee does not agree. The "..." is directed to the programmer where there is history for using this character.
Committee Response:
The Committee agrees.
asctime
is defined for these years, so there
is no justification for the restriction.
Committee Response:
The Committee disagrees; this has been discussed and
there was no consensus to make this change.
strftime
is the function that is
recommended.
strftime
and
wcsftime
functions should be provided.RSIZE_MAX
test or that the year number is
sensible.
Committee Response:
The Committee disagrees; these functions do not currently have the level of vulnerable issues this document is addressing.
size_t
to
rsize_t
in 5.8.1.1 para 3.Committee Response:
The Committee agrees.
Committee Response:
The Committee agrees; words along the lines of 7.1.3 #1 will be incorporated.
%s
and friends in scanf, which don't count the
skipped leading spaces.
Committee Response:
The Committee agrees.
RSIZE_MAX + 1
would
seem a better return value than 0
for the null
pointer and not-null-terminated cases.RSIZE_MAX + 1
will trigger appropriate alerts
in the other functions in this library, while zero will
just silently truncate strings. If RSIZE_MAX ==
SIZE_MAX
, this will still fall back to zero.
Committee Response:
The Committee disagrees, the return maxsize
is more algorithmically useful. Rationale will be
provided for this.
asctime
.Committee Response:
The output strings will match in most cases, the behavior
of asctime_s
is better defined. Rationale
will be provided for this.
Committee Response:
The Committee believes this is a rendering problem with the program you use to read the document.
Committee Response:
The Committee agrees.
_s
versions of the following functions, and
the general philosophy involving minimizing performance
impact.
strchr
,strcspn
,strpbrk
,strrchr
,strspn
andstrstr
Committee Response:
The Committee agrees.
tmpfile_s
,fopen_s
andfreopen_s
Committee Response:
The Committee agrees. A footnote will be added to clarify.
sprintf_s
and snprintf_s
will do
essentially if not exactly the same thing. Maybe only one
of them is needed.
Committee Response:
The Committee notes the concern.
Committee Response:
See GB02.
Committee Response:
This is a delete indicator, and will not be in the final version.
Committee Response:
The Committee agrees.
Committee Response:
The Committee agrees.
Committee Response:
The Committee disagrees,RSIZE_MAX
is always asize_t
and is not appropriate for a static initializer.
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.
Committee Response:
The Committee agrees. The "No assignment to
s
occurs." will be removed.
Committee Response:
The Committee agrees.
s
are unspecified".
Committee Response:
The Committee agrees.
maxsize ==
0
to the list of diagnosed undefined behavior.
Committee Response:
The Committee agrees.
qsort_s
return
void
instead of errno_t
?Committee Response:
The Committee agrees.
Committee Response:
See US06.
Committee Response:
The Committee agrees.
Committee Response:
It adds truncation, here will be words in the Rationale to clarify.
Committee Response:
The Committee believes it is clear that it represents the calendar year. Also see GB11.
Committee Response:
The Committee agrees; the wide versions will match the functionality of the narrow versions.
Committee Response:
The Committee agrees.
Committee Response:
This is intentional. The Editor will look at an alterative approach for this problem.
Committee Response:
Noted, also see US16.
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).
Committee Response:
The Committee believes that it is premature to standardize this feature at this time. Implementations may experiment with this feature if they wish.
Committee Response:
See NL01.
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.
Committee Response:
The Committee agrees.
strcpy_s
,strlcpy
,strcat_s
,strlcat
,asctime_s
,asctime_r
,gtime_s
,gtime_r
,localtime_s
andlocaltime_r
Committee Response:
See CA02.
tmpfile_s()
is identical to the existingtmpfile()
except for the style of returning the resultingFILE *
.Committee Response:
See US03.tmpnam_s()
is almost the same as the existingtmpnam_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 oftmpfile()
ormkstemp()
instead.Committee Response:
There will be words added to the Rationale to clarify this; the Committee believes having this function in the package helps with mechanical transition.strcpy_s()
is equivalent tostrlcpy()
. It seems like providing yet another safe version ofstrcpy()
would be confusing at best.Committee Response:
See CA02.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 existingscanf()
family in a compatible way. What's needed is a format modifier to indicate that the size is specified by a parameter, like the*
inprintf()
format strings. Sincescanf()
already uses*
for assignment suppression, a different character would be needed, but one could choose any unused format character and remain compatible with the existingscanf()
functions.Committee Response:
The Committee believes that the optional nature is not desirable.
Committee Response:
The committee agrees. Also see US01.
Committee Response:
This will be addressed.
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
andwcrtomb_s
Committee Response:
Yes, these will be considered.
_TRUNCATE
in
N1089.
Committee Response:
Yes, these will be considered.
tmpfile_s
, fopen_s
, and
freopen_s
functions should open their files in
a "safe" mode giving exclusive (non-shared) access.
Committee Response:
Yes, this will be done. Also see US03.
Committee Response:
Yes, these will be considered. Also see NL01.