From dev-return-22880-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Thu Feb 04 23:07:00 2010 Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 46038 invoked from network); 4 Feb 2010 23:07:00 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 4 Feb 2010 23:07:00 -0000 Received: (qmail 41525 invoked by uid 500); 4 Feb 2010 23:06:59 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 41429 invoked by uid 500); 4 Feb 2010 23:06:59 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 41421 invoked by uid 99); 4 Feb 2010 23:06:59 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Feb 2010 23:06:59 +0000 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=FM_FAKE_HELO_VERIZON,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [206.46.173.11] (HELO vms173011pub.verizon.net) (206.46.173.11) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 04 Feb 2010 23:06:50 +0000 Received: from black ([unknown] [173.69.27.49]) by vms173011.mailsrvcs.net (Sun Java(tm) System Messaging Server 7u2-7.02 32bit (built Apr 16 2009)) with ESMTPA id <0KXC00CTYAU8FL21@vms173011.mailsrvcs.net> for dev@apr.apache.org; Thu, 04 Feb 2010 17:06:12 -0600 (CST) Received: from bob by black with local (Exim 4.69) (envelope-from ) id 1NdAm0-0005dA-4A; Thu, 04 Feb 2010 18:06:08 -0500 Date: Thu, 04 Feb 2010 18:06:08 -0500 From: Bob Rossi To: Bojan Smojver Cc: dev@apr.apache.org Subject: Re: dbd p[v]b functions problem Message-id: <20100204230608.GB20966@brasko.net> Mail-followup-to: Bojan Smojver , dev@apr.apache.org References: <20100204224416.GA20966@brasko.net> <1265323919.1858.3.camel@shrek.rexursive.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: <1265323919.1858.3.camel@shrek.rexursive.com> User-Agent: Mutt/1.5.17+20080114 (2008-01-14) X-Virus-Checked: Checked by ClamAV on apache.org On Fri, Feb 05, 2010 at 09:51:59AM +1100, Bojan Smojver wrote: > On Thu, 2010-02-04 at 17:44 -0500, Bob Rossi wrote: > > Is this a design decision or a flaw? > > Design decision. > > Just to be clear, you are getting segfaults when you are NOT passing > pointers in, correct? Correct. > If you are doing that, you are misusing the API and causing the segfaults. Wow, I can't believe this is a design decision. It makes no sense to force the user to pass a pointer like this. It creates a burden on the user to make an lvalue for the constant. (Perhaps there are reasons unknown to me that forced this api to behave this way?) If you are bent on preserving this interface, does a new interface make sense, that allows the user to pass in the parameters, without passing in addresses? At this point, I either have to force the clients of my interface to pass in only pointers, or to pass in all strings followed by a NULL parameter. Each of these cases can be easily messed up, causing a segfault! It makes much more sense, in my mind, to follow the traditional variadic parameter approach like printf..., this interface is very hard to screw up by accident. Bob Rossi