On Jun 24, 2011 3:23 AM, "Bert Huijben" <bert_at_qqmail.nl> wrote:
>
>
>
> > -----Original Message-----
> > From: Greg Stein [mailto:gstein_at_gmail.com]
> > Sent: vrijdag 24 juni 2011 2:10
> > To: dev_at_subversion.apache.org
> > Subject: Re: svn commit: r1139080 -
> > /subversion/trunk/subversion/libsvn_wc/wc_db.c
> >
> > On Thu, Jun 23, 2011 at 17:20, <rhuijben_at_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
Received on 2011-06-24 13:25:22 CEST