Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:15602 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 36942 invoked by uid 1010); 25 Mar 2005 14:28:41 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 36927 invoked from network); 25 Mar 2005 14:28:41 -0000 Received: from unknown (HELO unwireduniverse.com) (127.0.0.1) by localhost with SMTP; 25 Mar 2005 14:28:41 -0000 X-Host-Fingerprint: 66.92.75.243 dsl092-075-243.bos1.dsl.speakeasy.net Linux 2.4/2.6 Received: from ([66.92.75.243:4055] helo=amber.vis-av.com) by pb1.pair.com (ecelerity HEAD r(5268)) with SMTP id 6A/A8-61605-91024424 for ; Fri, 25 Mar 2005 09:28:41 -0500 Received: (qmail 18762 invoked from network); 25 Mar 2005 14:28:37 -0000 Received: from unknown (HELO random.internal) (192.168.1.9) by amber.internal with SMTP; 25 Mar 2005 14:28:37 -0000 Received: (nullmailer pid 7533 invoked by uid 0); Fri, 25 Mar 2005 14:28:37 -0000 To: "Thies C\. Arntzen" Cc: internals@lists.php.net References: Reply-To: Derrell.Lipman@UnwiredUniverse.com Date: Fri, 25 Mar 2005 09:28:37 -0500 In-Reply-To: (Thies C. Arntzen's message of "Fri, 25 Mar 2005 14:20:02 +0100") Message-ID: User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Corporate Culture, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [PHP-DEV] pdo: patch to make leading colon unneeded for bound variables without breaking BC. From: Derrell.Lipman@UnwiredUniverse.com "Thies C. Arntzen" writes: > diff -u -w -r1.95 pdo_stmt.c > --- ext/pdo/pdo_stmt.c 24 Mar 2005 12:32:06 -0000 1.95 > +++ ext/pdo/pdo_stmt.c 25 Mar 2005 13:13:18 -0000 > @@ -242,6 +242,13 @@ > > hash = is_param ? stmt->bound_params : stmt->bound_columns; > > + if (param->name) { > + if (param->name[0] == ':') { > + param->name = param->name + 1; Sanity check... Without researching thoroughly, this "appears" to warrant further inspection. The field param->name is clearly a pointer since you're able to increment it. It seems likely, then, that param->name was dynamically allocated. If that's not the case, then you can stop reading. If it is, though, then by incrementing param->name, what happens when param->name is freed? I didn't see any place in the patch where it is marked as having been incremented nor anyplace where it is decremented in order to be freed. Cheers, Derrell