GNOME Bugzilla – Bug 774124
ascii_strto* are declared private
Last modified: 2017-11-20 20:04:56 UTC
For basic types like double, ascii_strto* are declared as private methods. They should be public.
For double the g_ascii_strtod function signature has been adapted with a Vala wrapper. So you would use double.parse ("1.2"); or double.try_parse ("1.2", result); The try_parse () method will return true if successful and the double in result. Does this not work for you?
For GSVG[1] I use ascii_strtod to parse numbers like "3.45mm". With this function I parse first part to get double value and output pointer used to generate a enum value to know its units, then no is not enough.
These methods are bound as string.to_*()
Created attachment 339392 [details] [review] Add an optional 'unparsed' parameter to double.try_parse() to return the unparsed part of the string
Created attachment 339393 [details] Test program for new optional parameter in double.try_parse () Program tests the original signature and new signature both work with the amended binding.
Created attachment 339394 [details] Test program for new optional parameter in double.try_parse () Program tests the original signature and new signature both work with the amended binding. This version also prints the double returned.
Its Ok for me. Can be this backported to 0.34?
Created attachment 347598 [details] [review] glib-2.0: Add optional 'unparsed' parameter to *.try_parse () This reintroduces a dropped feature of string.to_*() while returning the maybe available unparsed part of the string.
Review of attachment 347598 [details] [review]: This looks fine to me and keeps backwards compatibility by making the unparsed argument optional. Although strtoll applies to int64, strtoull applies to uint64 and strtod applies to double, it would be nice if Vala had a consistent API for all number types it supports. I'm not finding standard C functions for that. So Vala may need to generate the C code itself. Is this a good idea?
Review of attachment 347598 [details] [review]: It is good fore. Can be backported to 0.34?
(In reply to Al Thomas from comment #9) > Review of attachment 347598 [details] [review] [review]: > > This looks fine to me and keeps backwards compatibility by making the > unparsed argument optional. > Although strtoll applies to int64, strtoull applies to uint64 and strtod > applies to double, it > would be nice if Vala had a consistent API for all number types it supports. > I'm not finding standard > C functions for that. So Vala may need to generate the C code itself. Is > this a good idea? I think Vala can use standard C methods and GLib ones, mark as unstable until we have confidence on C code is secure enough.
*** Bug 789179 has been marked as a duplicate of this bug. ***
*** Bug 669278 has been marked as a duplicate of this bug. ***
Can you, please push, this patch to upstream? I need it for GSVG development.
Attachment 347598 [details] pushed as 1eb5044 - glib-2.0: Add optional 'unparsed' parameter to *.try_parse ()