Re: gparamspecs.c param_double_validate() doesn't support NaN/Inf?

["Andrew W. Nosenko" <andrew w nosenko gmail com>]

On Fri, Jan 9, 2009 at 8:03 PM, Andrew Paprocki <andrew ishiboo com> wrote:
> Well, it brings up a few issues.. If someone defined a param spec with
> a minimum/maximum value, Nan/Inf/-Inf are separate values that were
> previously disallowed by the current code. So in my mind, making every
> double param suddenly accept these values is a bit awkward. I'm not
> sure how easily GParamSpecDouble can be changed to add new fields so
> that params can specify whether they want to accept nan/inf
> explicitly. That part was more of a RFC.. making the patch is easy but
> I'm not sure what is an acceptable change.

First at all, could you provide any real-world example, where min/max
restriction on GParamSpec could be usefull?  The reason is simple:
when validation fails, the application has no way to know about it
and, therefore, to do anything usefull.  There just no interface for
such things, like "validation-fails-callback".  As consequence, any
validation should be done at the application level, before bringing
GObject/GParamSpec/GValue/etc machinery into game.  Hence, I hard to
imagine any usefull example of using restrcted GParamSpecs...

Second: Rules of comparison and other NaN/Inf related behavior
perfectly defined by C standard.  If application deals with them all
his work-time, why it should be confused and/or fail when one of
intermediate temporary variables occur not a built-in double type, but
container/wrapper designated for holding this double type?

-- 
Andrew W. Nosenko <andrew w nosenko gmail com>