[postgis-devel] breaking changes in varInt code and twkb
Sandro Santilli
strk at keybit.net
Wed Aug 27 07:10:41 PDT 2014
On Sat, Aug 23, 2014 at 07:24:09AM +0200, Sandro Santilli wrote:
> On Sat, Aug 23, 2014 at 12:03:11AM +0200, Nicklas Avén wrote:
> > Sandro
> >
> > in r12907 I did the switch to passing around **buf instead of *buf in
> > twkb and varint. That affects all the varInt types. I don't think you
> > have committed any code relying on varInt yet though. Right?
>
> Not in trunk, but I have it in a fork:
> https://github.com/strk/postgis/blob/mvt/liblwgeom/lwout_vt.c
Nicklas, I'm rebasing my branch against trunk now and hitting that interface
change of varint encoder taking **buf instead of *buf.
You made those functions return an integer, but they all return 0
unconditionally. Should they be returning void ?
> > I couldn't see any performance difference, but it gets a little cleaner
> > and is the first step to clean up more in all the values thrown around
> > in the twkb code.
My code looked like this:
/* encode X parameter */
to = varint_s32_encode_buf(dc->x, to);
/* encode Y parameter */
to = varint_s32_encode_buf(dc->y, to);
To adapt to your change it would need to be converted to this:
/* encode X parameter */
if ( varint_s32_encode_buf(dc->x, &to) ) { lwerror(...); return; }
/* encode Y parameter */
if ( varint_s32_encode_buf(dc->y, &to) ) { lwerror(...); return; }
Is that the idea ?
Note that liblwgeom.h defines LW_SUCCESS as 1 and LW_FAILURE as 0.
I know it doesn't allow to return different kind of errors, but that's
what we have right now used elsewere.
In what circumstance could those functions return an error ?
--strk;
() ASCII ribbon campaign -- Keep it simple !
/\ http://strk.keybit.net/rants/ascii_mails.txt
More information about the postgis-devel
mailing list