[postgis-devel] [postgis-tickets] r14592 - Patch from Sebastiaan Couwenberg to fix test_wkb_out_point failure on hppa & mips.

[Sandro Santilli]

On Wed, Jan 13, 2016 at 01:45:07AM -0500, Regina Obe wrote:
> Greg,
> 
> I committed to both trunk and branch 2.2.  I blindly trusted Sebastian's
> judgement on things since it was just a regression test (not code change),
> he had tested on platforms I have no access to,
> and the tests still passed under my mingw64 install.  I'm not knowledgeable
> enough in C to judge code.
> 
> Perhaps Paul , Sandro, or others can chime in on this.

I've no major problem with the change as it's only in the tester,
but Greg makes a good point about the need to find a portable way
to represent a NaN, if that's what we're using for a POINT EMPY
in WKB form.

WKB supports big-endian or little-endian indication, to be
architecture independent, but if we need to be able to transport
a POINT EMPTY in WKB form from a vax to an x86...

This is probably best discussed in
https://trac.osgeo.org/postgis/ticket/3426

--strk;


> 
> Thanks,
> Regina
> 
> -----Original Message-----
> From: Greg Troxel [mailto:gdt at ir.bbn.com] 
> Sent: Tuesday, January 12, 2016 7:44 PM
> To: Regina Obe <lr at pcorp.us>
> Cc: postgis-devel at lists.osgeo.org
> Subject: Re: [postgis-tickets] r14592 - Patch from Sebastiaan Couwenberg to
> fix test_wkb_out_point failure on hppa & mips.
> 
> 
> Regina Obe <lr at pcorp.us> writes:
> 
> > Author: robe
> > Date: 2016-01-12 16:36:35 -0800 (Tue, 12 Jan 2016) New Revision: 14592
> >
> > Modified:
> >    branches/2.2/liblwgeom/cunit/cu_out_wkb.c
> > Log:
> > Patch from Sebastiaan Couwenberg to fix test_wkb_out_point failure on hppa
> & mips.
> > references #3426
> 
> I'm a little surprised at changes going onto the release branch without
> first being on trunk and having review and then getting cherrypicked onto
> the release branch.
> 
> > +/* parisc and mips (at least some processors) have a different nan 
> > +representation from other arches. */ #if !defined(__hppa__) && 
> > +!defined(__mips__) # define nan_val( v1, v2)  v1 #else # define 
> > +nan_val( v1, v2)  v2 #endif
> 
> This seems quite awkward.  It would seem the tests should be grounded in the
> standards (presumably postgis requires IEEE754 to start and doesn't work on
> the vax :-).  Isn't there some way to start with a nan expressed as a
> double, and then to convert that to a sql representation?  Or to write an
> "isnan_wkb" function that takes the string/hex representation, extracts a
> double, and then uses the C99-specified isnan(3) procedures.
> Encoding of IEEE754 values into hex and having them in the tests seems
> nonrobust, and it seems extra fragile to have switches by arch.
> 
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/postgis-devel

-- 

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html