reverted commits

[Havoc Pennington]

Hi,

Ralf Habacker wrote:
> double dbus_strtod(const char *nptr, char **endptr)
> {
>     if (nptr && strlen(nptr) == 4 && nptr[0] == '0' && nptr[1] == 'x' &&
> nptr[2] == 'f' && nptr[3] == '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().

Havoc