hp at redhat.com
Fri Jun 22 11:37:05 PDT 2007
Ralf Habacker wrote:
> double dbus_strtod(const char *nptr, char **endptr)
> if (nptr && strlen(nptr) == 4 && nptr == '0' && nptr == 'x' &&
> nptr == 'f' && nptr == 'f')
> if (endptr)
> *endptr = nptr+4;
> return 0.0;
> return strtod(nptr,endptr);
> There are still some issues. This function will be used in libdbus and
> dbus-send. Therefore it must be a public dbus function or how to proceed ?
Are you serious? You need to think about this patch some more.
Right now the test suite checks that _dbus_string_parse_double can parse
a hex number, which linux strtod() does and Windows strtod() does not.
There are two possible solutions:
- decide that we don't need to parse hex numbers by reviewing the uses
of _dbus_string_parse_double. Remove test case if no uses rely on
being able to parse hex. Maybe add some code to string_parse_double
to set an error if the string starts with 0x or 0X, just to be sure
we never rely on this on either platform.
- decide that we do need to parse hex numbers. Make it parse hex
numbers on windows, e.g. by falling back to strtol or
_dbus_string_parse_int if the string starts with 0x or 0X.
There is no planet on which we need a function that parses 0xff and no
other hex numbers, and interprets 0xff as 0.0 instead of 255.
For dbus-send, I see no reason we need to support hex numbers, so just
leaving dbus-send as-is is fine.
I have not reviewed other existing uses of string_parse_double().
More information about the dbus