Bug 7960 - Weird D-BUS problem with strtod usage
Summary: Weird D-BUS problem with strtod usage
Status: RESOLVED FIXED
Alias: None
Product: dbus
Classification: Unclassified
Component: core (show other bugs)
Version: unspecified
Hardware: SPARC Solaris
: medium normal
Assignee: Havoc Pennington
QA Contact: John (J5) Palmieri
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-22 13:22 UTC by Brian Cameron
Modified: 2011-03-09 07:21 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Brian Cameron 2006-08-22 13:22:22 UTC
When I run "make check" on Solaris, I see this output - note failed test:

make[3]: Entering directory
`/export/home/jds/packages/BUILD/dbus-test/dbus-0.62/dbus'
Test data in ../test/data
dbus-test: running string tests
dbus-test: checking for memleaks
dbus-test: running sysdeps tests
Failed to parse 0xff correctly, got: 0.000000

The problem seems to be with the strtod call that we see in the
dbus/dbus-sysdeps.c code.  

I created a small test program containing a call to strtod. If it is compiled
with c99 compiler then strtod recognizes a hex string as a float but if cc is
used strtod recognizes a hex string as an integer.

I tried compiling dbus with c99 compiler. This worked except for the source file
dbus-sysdeps-utils.c which I had to compile by hand with cc compiler. Then make
check ran successfully.

I am not sure what we want to do about this or if it is Solaris specific. 
Perhaps this is compiler (or compiler option) specific?

The code that calls strtod for this failed test is ascii_strtod function in the
dbus/dbus-sysdeps.c code and this is only built with --enable-tests is specified
(note #ifdef DBUS_BUILD_TESTS) and is not part of the delivered dbus code.
However, I also notice that dbus-send calls strtod () in the append_arg
function, so perhaps this test is highlighting a bug that could appear there?

When I comment out this failing test and build with cc then make check pases. 

Perhaps we should be using a different function than strtod that doesn't
have compiler issues like this?  Or should we use special compiler options when
building certain files in D-BUS, do you think?
Comment 1 Brian Cameron 2006-08-22 13:27:55 UTC
For reference:

  http://www.opensolaris.org/jive/thread.jspa?threadID=12383
Comment 2 John (J5) Palmieri 2006-08-22 14:30:05 UTC
is there another function we could use? Looks like a Solaris issue so we could
have a workaround on Solaris but I much rather find a function that would work
on all platforms. According to the man page hex is legal and there are no notes
to the contrary.  What does the man page say on Solaris?
Comment 3 Padraig O'Briain 2006-08-30 03:07:08 UTC
I think that this bug should be closed.

If we compile dbus with -xc99 option of compiler then the problem does not occur.
Comment 4 John (J5) Palmieri 2006-08-30 09:57:00 UTC
Perhaps we should include a patch witch detects the sun compiler and adds the
-xc99 flag before closing this
Comment 5 Brian Cameron 2006-08-30 10:19:44 UTC
I think it's only necessary to add this flag when compiling with the Sun Studio
compiler.  Here is how you would construct a configure test for this compiler.
And should be a simple matter of adding -xc99 to the CFLAGS if the test returns
true (if g_have_sunstudio_visibility=yes).

AC_MSG_CHECKING([whether using Sun Studio C compiler])
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#if defined(__SUNPRO_C)
#else
# include "error: this is not Sun Studio."
#endif
]], [[]])], [ g_have_sunstudio_visibility=yes ], [ g_have_sunstudio_visibility=no ])
AC_MSG_RESULT($g_have_sunstudio_visibility)
Comment 6 Havoc Pennington 2006-08-30 12:29:21 UTC
If parsing hex is really c99-only, as someone on the list says also, then 
there are other compilers besides Sun that will give problems.

Maybe we should try and figure out if we really need to parse hex or it's just 
in the test suite for no good reason.
Comment 7 Brian Cameron 2006-09-22 11:54:45 UTC
Perhaps the documentation just needs to mention that building with C99 enabled
(e.g. -xc99 when using the Sun Studio compiler) is needed.

Perhaps this "make check" test should be moved into configure so that configure
fails if the user isn't building with C99 options?

Comment 8 Havoc Pennington 2006-09-22 12:48:05 UTC
Again, I don't think we want to require c99. Either we should confirm that we 
don't need to support hex parsing, or we should add a way to parse hex that's 
portable.
Comment 9 Christian Ehrlicher 2006-12-06 03:51:31 UTC
We've the same problem on windows ... 
I also found a workaround for non c99 compliant systems ->
http://www.netlib.org/fp/dtoa.c
Comment 10 Havoc Pennington 2006-12-06 07:36:01 UTC
maintaining that is some serious overkill if we don't need to parse hex 
anyhow, though, as I believe we don't...
Comment 11 Benjamin Close 2008-01-11 02:38:41 UTC
Bugzilla Upgrade Mass Bug Change

NEEDSINFO state was removed in Bugzilla 3.x, reopening any bugs previously listed as NEEDSINFO.

  - benjsc
    fd.o Wrangler
Comment 12 John (J5) Palmieri 2008-01-14 12:09:29 UTC
committed.  thanks
Comment 13 John (J5) Palmieri 2008-01-14 12:13:07 UTC
woops, ignore the above as I did not commit this.  I mistakenly added the comment to the wrong bug.
Comment 14 Simon McVittie 2011-03-09 07:21:18 UTC
Fixed back in 2007 (between 1.1.0 and 1.1.2), while this bug was in NEEDINFO state:

commit ed57b9c663db89370055c5196e7e0b537647e9ef
Author: Havoc Pennington <hp@redhat.com>
Date:   2007-07-12 22:18:05 +0000

    2007-07-12  Havoc Pennington  <hp@redhat.com>
    
        * dbus/dbus-sysdeps-util.c (_dbus_sysdeps_test): invert the test
        for parsing hex as double to be sure it fails to work
    
        * dbus/dbus-sysdeps.c (_dbus_string_parse_double): don't allow hex numbers.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.