From owner-freebsd-hackers@FreeBSD.ORG Wed Apr 23 19:22:36 2008 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 609791065673; Wed, 23 Apr 2008 19:22:36 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (mail.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 2CCC58FC15; Wed, 23 Apr 2008 19:22:36 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id 3FA615BB1; Wed, 23 Apr 2008 11:54:31 -0700 (PDT) To: Robert Watson In-reply-to: Your message of "Wed, 23 Apr 2008 11:03:10 BST." <20080423105319.V35222@fledge.watson.org> Date: Wed, 23 Apr 2008 11:54:30 -0700 From: Bakul Shah Message-Id: <20080423185431.3FA615BB1@mail.bitblocks.com> Cc: Garrett Cooper , hackers@freebsd.org Subject: Re: Fwd: strdup(NULL) supposed to create SIGSEGV? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2008 19:22:36 -0000 On Wed, 23 Apr 2008 11:03:10 BST Robert Watson wrote: > On Wed, 23 Apr 2008, Garrett Cooper wrote: > > Of course I did some more research after you guys gave me some replies and > > realized I'm not the first person to bumble across this fact, but I haven't > > found FreeBSD or Linux documentation supporting that errata. It was harmless > > in my tiny program, but I would hate to be someone adding that assumption to > > a larger project with multiple threads and a fair number of lines... > > Consider the following counter-arguments: > > - In C, a string is a sequence of non-nul characters followed by a nul > character terminating the string. NULL is therefore not a valid string. > > - Currently, strdup(3) has an unambiguous error model: if it returns a > non-NULL string has succeeded, and if it has failed, it returns NULL and > sets errno. If NULL becomes a successful return from strdup(3), then this > is no longer the case, breaking the assumptions of currently correct > consumers. I suspect Garrett has a more fundamental misunderstanding. C is a low level language and for efficiency sake most of its standard functions *do not check* that their inputs are legal -- it is the caller's responsibility to give valid inputs and when that is not done, all bets are off! In general a NULL is an illegal value to pass in place of any kind of pointer. The *exception* is where a function is explicitly prepared to handle NULLs. One must read its man page carefully and if it doesn't say anything about how NULLs in place of ptrs are handled, one must not pass in NULLs! He should also note that function specifications (e.g. man pages) will specify what are legal inputs but usually they will *not* specify what happens when illegal inputs are given since a) that set is usually much much larger, and b) the effect is likely to be machine dependent. FWIW!