[postgis-devel] [wktraster] Core tests failure for r5841

strk strk at keybit.net
Thu Jan 13 05:12:47 PST 2011


On Thu, Jan 13, 2011 at 01:11:07PM +0100, Jorge Arévalo wrote:
> On Thu, Jan 13, 2011 at 10:08 AM, strk <strk at keybit.net> wrote:
> > On Thu, Jan 13, 2011 at 01:12:58AM +0000, Mateusz Loskot wrote:
> >
> >> "Something must have gone wrong on Mat`s one" means either GCC team has
> >> screwed their compiler and it generates rubbish, or we have problem in
> >> PostGIS. Which one you vote for?
> >
> > Hey...
> > We're talking about a message of this form:
> >
> >  WARNING:  Initial pixel value for 16BSI band got truncated from XXX to YYY
> >
> > Sounds like the problem isn't going unnoticed, which is good.
> > That's all that test is checking: if numbers that don't fit in 16BSI
> > representation are correctly WARNED about.
> >
> > I vote for "a problem with testing framework" :)
> >
> > --strk;
> >
> >  ()   Free GIS & Flash consultant/developer
> >  /\   http://strk.keybit.net/services.html
> > _______________________________________________
> > postgis-devel mailing list
> > postgis-devel at postgis.refractions.net
> > http://postgis.refractions.net/mailman/listinfo/postgis-devel
> >
> 
> Mmmm... Mateusz is right. In case of 210000.46, for example. When you
> cast from double to uint16:
> 
> 1.- First, discard decimal part --> 210000
> 2.- Convert the real part to integer
> 
> 210000 = 0b110011010001010000
> 
> If you get the 16 LSB --> 0b0011010001010000 = 13392
> 
> But if, as the standard says, there's UB with these casts, how should
> we write a test?

You might simplify the WARNING message so to not include the
number coming out from the truncation, or make the truncation
somewhat predictable by an explicit clamping in a known range.

--strk;

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



More information about the postgis-devel mailing list