[postgis-devel] breaking changes in varInt code and twkb

[Nicklas Avén]

Actually I haven't thought about it properly. As you say 0 for success is a bad idea since it doesn't match LW_SUCCESS.
So it should be LW_SUCCESS or void. What do you think?
Sorry for leaving it un finnished.
/Nicklas


Skickat från min Samsung Mobil.

<div>-------- Originalmeddelande --------</div><div>Från: Sandro Santilli <strk at keybit.net> </div><div>Datum:2014-08-27  16:10  (GMT+01:00) </div><div>Till: PostGIS Development Discussion <postgis-devel at lists.osgeo.org> </div><div>Kopia: Nicklas Avén <nicklas.aven at jordogskog.no> </div><div>Rubrik: Re: [postgis-devel] breaking changes in varInt code and twkb </div><div>
</div>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  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20140827/4976cc92/attachment.html>