Re: gparamspecs.c param_double_validate() doesn't support NaN/Inf?
- From: "Andrew W. Nosenko" <andrew w nosenko gmail com>
- To: "Andrew Paprocki" <andrew ishiboo com>
- Cc: Michael Natterer <mitch gimp org>, gtk-devel-list gnome org
- Subject: Re: gparamspecs.c param_double_validate() doesn't support NaN/Inf?
- Date: Sat, 10 Jan 2009 13:42:31 +0200
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>
] [Thread Prev