From owner-svn-src-head@freebsd.org Mon May 28 08:38:04 2018 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 628E9F73EA7; Mon, 28 May 2018 08:38:04 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail110.syd.optusnet.com.au (mail110.syd.optusnet.com.au [211.29.132.97]) by mx1.freebsd.org (Postfix) with ESMTP id D64A6834DB; Mon, 28 May 2018 08:38:03 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from [192.168.0.102] (c110-21-101-228.carlnfd1.nsw.optusnet.com.au [110.21.101.228]) by mail110.syd.optusnet.com.au (Postfix) with ESMTPS id 4357A1027B2; Mon, 28 May 2018 18:37:55 +1000 (AEST) Date: Mon, 28 May 2018 18:37:54 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Marcelo Araujo cc: src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r334275 - head/lib/libc/string In-Reply-To: <201805280501.w4S51hbH046599@repo.freebsd.org> Message-ID: <20180528155019.W2534@besplex.bde.org> References: <201805280501.w4S51hbH046599@repo.freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.2 cv=FNpr/6gs c=1 sm=1 tr=0 a=PalzARQSbocsUSjMRkwAPg==:117 a=PalzARQSbocsUSjMRkwAPg==:17 a=kj9zAlcOel0A:10 a=cI8g69VjL0PoBxxjEq8A:9 a=CjuIK1q_8ugA:10 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2018 08:38:04 -0000 On Mon, 28 May 2018, Marcelo Araujo wrote: > Log: > Update strsep(3) EXAMPLE section regards the usage of assert(3). > > As many people has pointed out, using assert(3) shall be not the best approach > to verify if strdup(3) has allocated memory to string. > > Reviewed by: imp > Modified: head/lib/libc/string/strsep.3 > ============================================================================== > --- head/lib/libc/string/strsep.3 Mon May 28 04:38:10 2018 (r334274) > +++ head/lib/libc/string/strsep.3 Mon May 28 05:01:42 2018 (r334275) > @@ -31,7 +31,7 @@ > .\" @(#)strsep.3 8.1 (Berkeley) 6/9/93 > .\" $FreeBSD$ > .\" > -.Dd December 5, 2008 > +.Dd May 28, 2018 > .Dt STRSEP 3 > .Os > .Sh NAME > @@ -86,12 +86,12 @@ to parse a string, and prints each token in separate l > char *token, *string, *tofree; > > tofree = string = strdup("abc,def,ghi"); > -assert(string != NULL); > +if (string != NULL) > + while ((token = strsep(&string, ",")) != NULL) > + printf("%s\en", token); > > -while ((token = strsep(&string, ",")) != NULL) > - printf("%s\en", token); > - > free(tofree); > +free(string); > .Ed > .Pp > The following uses This is even worse than before. Errors are now mishandled in all cases by silently ignoring them. On most arches, null pointers are handled better than with assert() by the default error handling of sending a SIGSEGV to the process; this normally terminates it and dumps core. All assert() does is give a message that is only slightly better than nothing when it work, and then sends a SIGABRT to the process after breaking restartability by doing this in the non-returning functions abort(). That is without NDEBUG. NDEBUG gives the better default error handling. Note that assert() can't be used in signal handlers since it is required to print to stderr due to C not having any output methods except stdio. Even printing to stderr is fragile, especially after malloc() failures, since stderr might be buffered and delayed allocation of its buffer might fail. The FreeBSD implementation falls back to unbuffered then (or fails in setvbuf()), but the C standard doesn't require this. malloc() failures "can't happen" anyway, especially for strdup(). I used to test them using rlimits. IIRC, ulimit -d and ulimit -m used to work to restrict malloc() when malloc() used sbrk(). But now malloc() uses mmap() and limits don't work for it. Also, malloc() on at least amd64 now takes more than 2MB before doing anything (2MB for __je_extents_rtree and a mere few hundred KB for other parts of malloc()). malloc() might fail, but hundreds if not thousands of small strdup()s can probably be done in just the slop required to fit malloc()'s overhead. Bruce