[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