RE: [bug-cgicc] possible bug in getDoubleValue

[Stephen F. Booth]

> Using cgicc for the first time, I came across some behavior which I
could
> not explain.  I have distilled the code to a minimum which still
exhibits
> the problem, and have taken the liberty to pack everything in a
gzipped
> tarball attached to this message.  I have included the recommended
output
> of support/config.guess and ./configure in the aptly named file out.

I compiled your code and got the same result- this is a bug.  I'll
elucidate more below.

> The problem I have encountered is in the getDoubleValue method of a
form
> parameter.  If I invoke this method without MIN and MIX limits (i.e.
as
> getDoubleValue()), and pass a negative value, the result is an
extremely
> small number (something like 2.22507e-308) and not the expected value.
If
> I specify MIN and MAX limits, the result is as expected.  If I pass a
> positive value, the result is as expected (regardless if limits are
> specified or not).  If I invoke the getIntegerValue method, the
results
> are
> as expected in any case.

The flaw was in my logic.  I was treating getIntegerValue() and
getDoubleValue() analogously in the way I was setting default parameters
for the method calls.  The values LONG_MIN and LONG_MAX refer to the
smallest and largest value that a long integer can have.  So obviously a
long can never be smaller than LONG_MIN, which is why LONG_MIN is the
default value for the lower bound in getIntegerValue().  I assumed
(incorrectly) that DBL_MIN and DBL_MAX could be used similarly.  I
searched through my header files and located the definition of those, in
/usr/lib/i686-pc-linux-gnu/g++/3.2/something or other/float.h.  Here are
those values:

   /* Minimum normalised double */
#undef DBL_MIN
#define DBL_MIN 2.2250738585072014e-308
   /* Maximum double */
#undef DBL_MAX
#define DBL_MAX 1.7976931348623157e+308

The value of DBL_MIN, not surprisingly, is the value that one sees
without passing a minimum or maximum value.  DBL_MAX is the largest
double, whereas DBL_MIN is the smallest double where distance from zero
is concerned- not the "largest negative" double as I originally thought.
So in your example, -10 is much smaller than DBL_MIN (its distance from
zero is greater), so getDoubleValue() was limiting the return value
(which it should) to DBL_MIN.

I was able to fix this problem, however I'm not sure if it is a correct
fix.  In FormEntry.h, if you change DBL_MIN in line 258 to -DBL_MAX the
problem will go away.  I'm not sure this is correct, though, because I'm
not sure that -DBL_MAX is the smallest (or largest negative) value that
a double can have.  

In any case, when I get my CVS access fixed I will change it in the
repository.  If I ever get myself in gear I will roll a new release.

Thanks for reporting this!

-Stephen

> Instead of using a form, I have used a simple href link like this:
> <a href="/cgi-bin/getDoubleValue_bug?value=-10.5>
> I do not see this as a problem, although I could be wrong.
> 
> The tarball contains these files:
> out - the output of support/config.guess and ./configure, as suggested
> getDoubleValue_bug.cpp - a short program invoking the getIntegerValue
and
> getDoubleValue methods with and without MIN and MAX limits, and
generating
> a simple HTML document with the results
> Makefile - to build the above program
> getDoubleValue_bug.html - simple Web page to invoke the above program
with
> different values
> 
> I have taken a glance at the source code for getDoubleValue, but could
not
> find anything that seemed to be the obvious culprit.  Perhaps I am
just
> using the cgicc package incorrectly.  Any help in this matter would be
> very
> much appreciated.
> 
> Thank you,
> Carsten Gehrke
> 
> 
> --
>
========================================================================
>                              Carsten P. Gehrke
>                       mailto:address@hidden
>
========================================================================