From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/6101 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: New static analysis results Date: Fri, 5 Sep 2014 17:23:34 -0400 Message-ID: <20140905212334.GS23797@brightrain.aerifal.cx> References: <20140904171357.GB23797@brightrain.aerifal.cx> <20140905180252.GO23797@brightrain.aerifal.cx> <20140905185338.GR23797@brightrain.aerifal.cx> <1409950252.4856.83.camel@eris.loria.fr> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1409952239 26858 80.91.229.3 (5 Sep 2014 21:23:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Sep 2014 21:23:59 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-6114-gllmg-musl=m.gmane.org@lists.openwall.com Fri Sep 05 23:23:52 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XQ0yy-0007b4-OD for gllmg-musl@plane.gmane.org; Fri, 05 Sep 2014 23:23:48 +0200 Original-Received: (qmail 32354 invoked by uid 550); 5 Sep 2014 21:23:47 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 32346 invoked from network); 5 Sep 2014 21:23:47 -0000 Content-Disposition: inline In-Reply-To: <1409950252.4856.83.camel@eris.loria.fr> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:6101 Archived-At: 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