Date: Fri, 5 Sep 2014 17:23:34 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: New static analysis results On Fri, Sep 05, 2014 at 10:50:52PM +0200, Jens Gustedt wrote: > Am Freitag, den 05.09.2014, 14:53 -0400 schrieb Rich Felker: > > See also asctime: it's even worse, specified to be UB, via potential > > buffer overflow, if the values are outside of the expected range. > > > > These functions really just should not be used for anything. Short of > > rolling your own, strftime is the only correct way to format time as a > > string. > > the corresponding xxx_s functions from Annex K are a bit better, here. > > > At some point it would be nice to make a big list of standard C > > functions that are utterly unusable due to UB on errors. Unusable due > > to lack of thread safety is another big area, too. > > Annex K can basically be read as such a list (for C itself, not POSIX) > and gives replacements for them, I think. I don't think so. Out of Annex K, here are the functions that replace a fundamentally unusable (due to UB) function with the same name minus the final _s (5): sprintf_s (but snprintf already did it better) vsprintf_s (ditto) gets_s (but gets was removed, and fgets already did it better) asctime_s (but strftime already did it better) ctime_s (ditto) So from this first group, I would call them all utterly useless replacements -- they're replacing things that already had better replacements. Second, the ones which replace a function that's unusable due to lack of thread-safety (5): strtok_s strerror_s wcstok_s gmtime_s localtime_s For all of these, POSIX already replaced them with _r versions; the _s versions are mostly gratuitous duplicates with the same or worse interfaces. So they're "useful" only for plain-C without POSIX. And next, the ones which replace a function that's usable in a thread-safe manner, but lacks a context, necessitating the use of TLS for context (2): bsearch_s qsort_s These seem like welcome additions. And finally, the ones which have nothing to do with fixing a problem in the function they 'replace' (52): tmpfile_s tmpnam_s fopen_s freopen_s fprintf_s fscanf_s printf_s scanf_s snprintf_s sscanf_s vfprintf_s vfscanf_s vprintf_s vscanf_s vsnprintf_s vsscanf_s getenv_s wctomb_s mbstowcs_s wcstombs_s memcpy_s memmove_s strcpy_s strncpy_s strcat_s strncat_s memset_s strnlen_s fwprintf_s fwscanf_s snwprintf_s swprintf_s swscanf_s vfwprintf_s vfwscanf_s vsnwprintf_s vswprintf_s vswscanf_s vwprintf_s vwscanf_s wprintf_s wscanf_s wcscpy_s wcsncpy_s wmemcpy_s wmemmove_s wcscat_s wcsncat_s wcsnlen_s wcrtomb_s mbsrtowcs_s wcsrtombs_s > Implementing these functions, using them with a constraint handler > that is set to ignore_handler_s, and checking for the return values of > the functions is a realistic alternative to all this UB stuff. Setting constraint handler is not thread-safe or library-safe, so it's not a practical solution. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.