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 9:23 PM, Michael Natterer <mitch gimp org> wrote:
> On Fri, 2009-01-09 at 13:03 -0500, Andrew Paprocki wrote:
>> On Fri, Jan 9, 2009 at 7:11 AM, Michael Natterer <mitch gimp org> wrote:
>> >> Should I patch GParamSpecDouble to have two :1 fields for 'allow_nan',
>> >> 'allow_inf' and make param_double_validate do the correct thing with
>> >> isnan()/isinf()?
>> >
>> > I think you have a very good point here and that use case is entirely
>> > reasonable.
>> >
>> > Would you please file this as enhancement request against GObject?
>> >
>> > An attached patch that follows the coding style nicely plus some
>> > code to test the feature in gobject/tests will increase the
>> > probability of this becoming committed significantly ;)
>>
>> 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.
>
> Of course the default would be to not accept these values. We can't
> change the behavior of existing code in such a way.
>

Excuse me, but you indeed think that anyone, who uses 'double' (as C
type) even expected that container for these 'double' restricts theirs
"field-of-allowed-values" (sorry, I don't know appropriate English
term, may be "value domain"?).

Moreover, I was _very_ surprising that NaN/Inf are not allowed!  I
never ever was able to imagine such!

About incompatibility: your program works not with GValues itself.
GValues are just containers used temporary for passing 'double's (in
this case).  The real work done with 'doubles' anyway.  NaN/inf are
allowed values for double that can occur at any time starting from
input and ending intermediate computations.  Therefore, your program
should be Nan/Info aware anyway.  I don't even say about cases when
these values used directly and especially, like in one of my program,
but, fortunatelly, I didn't found generic properties interface of
GObject featurefull enough and used own accessor functions, therefore
just worked around/didn't hit into this bug (yes, I would to consider
it as bug).