After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 567491 - gparamspecs.c param_double_validate() always fails NaN/Inf/-Inf values
gparamspecs.c param_double_validate() always fails NaN/Inf/-Inf values
Status: RESOLVED OBSOLETE
Product: glib
Classification: Platform
Component: gobject
2.19.x
Other All
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2009-01-12 13:29 UTC by Andrew Paprocki
Modified: 2018-05-24 11:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to GParamSpecDouble and param_double_validate() (1.72 KB, patch)
2009-01-12 13:30 UTC, Andrew Paprocki
none Details | Review

Description Andrew Paprocki 2009-01-12 13:29:56 UTC
Please describe the problem:
Double properties can not currently receive NaN/Inf/-Inf values because param_double_validate() does not allow for them. The CLAMP() logic will always fail. To preserve existing behavior, properties must continue to reject these values, but GParamSpecDouble should be modified to include allow_nan/allow_inf fields so that a property can allow such values.

Steps to reproduce:


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 Andrew Paprocki 2009-01-12 13:30:29 UTC
Created attachment 126270 [details] [review]
Patch to GParamSpecDouble and param_double_validate()
Comment 2 Andrew Paprocki 2009-01-12 13:31:33 UTC
I would like someone to test this on MSVC since it has different built-ins for the math functions. I don't have an environment set up here to easily test.
Comment 3 Michael Natterer 2009-01-12 21:03:12 UTC
Ouch, I didn't notice that GParamSpecDouble has not a single flag yet
and needs structure size change to support this. Unfortunately
this (or whatever similar patch) has to wait until GLib 3.0 :-(
Comment 4 Andrew Paprocki 2009-01-12 21:51:36 UTC
That is why I was suggesting an implicit workaround for GLib 2. I was suggesting that if the app had not explicitly set a minimum/maximum value (the defaults are -G_MAXDOUBLE/G_MAXDOUBLE), then NaN/Inf/-Inf would be allowed. If the app did in fact set an explicit range, then they would be rejected. It is not ideal, but it is the only real way I can see to avoid a structure change on GParamSpecDouble.
Comment 5 GNOME Infrastructure Team 2018-05-24 11:40:39 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/183.