[postgis-devel] [postgis-tickets] r14592 - Patch from Sebastiaan Couwenberg to fix test_wkb_out_point failure on hppa & mips.
Paul Ramsey
pramsey at cleverelephant.ca
Wed Jan 13 06:21:45 PST 2016
We already have a platform-dependent generator of NaN-in-hex, and it’s in the WKB output code :) If we start comparing the output of WKB to a generated NaN in the tester, we might as well remove the tests (which I’m fine w/). Or find another Nan generator to use? We use any defined NAN macro, or if there isn’t one, we use
#ifndef NAN
#define NAN 0.0/0.0
#endif
P
> On Jan 13, 2016, at 3:24 AM, Sandro Santilli <strk at keybit.net> wrote:
>
> 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 <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 <http://strk.keybit.net/services.html>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org <mailto:postgis-devel at lists.osgeo.org>
> http://lists.osgeo.org/mailman/listinfo/postgis-devel <http://lists.osgeo.org/mailman/listinfo/postgis-devel>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20160113/7355e6e4/attachment.html>
More information about the postgis-devel
mailing list