[ sigh. virtual keyboard typo. "inspection" ]
On Jun 24, 2011 7:24 AM, "Greg Stein" <gst...@gmail.com> wrote: > > > On Jun 24, 2011 3:23 AM, "Bert Huijben" <b...@qqmail.nl> wrote: > > > > > > > > > -----Original Message----- > > > From: Greg Stein [mailto:gst...@gmail.com] > > > Sent: vrijdag 24 juni 2011 2:10 > > > To: dev@subversion.apache.org > > > Subject: Re: svn commit: r1139080 - > > > /subversion/trunk/subversion/libsvn_wc/wc_db.c > > > > > > On Thu, Jun 23, 2011 at 17:20, <rhuij...@apache.org> wrote: > > > >... > > > > +++ subversion/trunk/subversion/libsvn_wc/wc_db.c Thu Jun 23 21:20:49 > > > 2011 > > > > @@ -6068,16 +6068,15 @@ op_delete_txn(void *baton, > > > > SVN_ERR(svn_sqlite__step(&have_row, stmt)); > > > > if (have_row) > > > > { > > > > - const char *absent_path > > > > - = svn_dirent_local_style(svn_sqlite__column_text(stmt, 0, > > > scratch_pool), > > > > - scratch_pool); > > > > + const char *absent_path = svn_sqlite__column_text(stmt, 0, > > > scratch_pool); > > > > > > You can pass NULL rather than scratch_pool since the value will > > > immediately be joined with the wcroot's path. > > > > Are you sure this is guaranteed to be safe? > > > > The svn_error_createf() contains a svn_sqlite__reset(stmt) as child > > argument, so I would guess whether this is safe depends on the evaluation > > order. > > (So I left it as is, just to be sure) > > Ah, hell... you're right. I hate that "feature" of our error creation, that it may also wrap existing errors. Almost uniformly, I have never seen the passing of child errors to the create function. You have to look hard to see it, where casual ibsoection misses it. > > Sigh. > > Cheers, > -g
