Solved

Linux atof problem

Posted on 1997-04-30
3
478 Views
Last Modified: 2013-12-26
I have a C++ program that reads in a binary string, parses it into character arrays and converts some of them to doubles with atof.  It works fine on the Sun Sparcs on which the data is stored.  However, when I compile and run the program on Linux, the program bombs.  After debugging with gdb, I found that a string goes into atof as "1201" and comes out as 12019.  The Linux system nfs mounts the data disk from the same Sun.  I examined the "1201" in binary form, and it looks the same as on the Sun.

Thanks in advance.
0
Comment
Question by:jshirer
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 2
3 Comments
 
LVL 3

Accepted Solution

by:
dhm earned 100 total points
ID: 1292728
Do you #include a header file that declares "double atof(const char *)"?  (Either <stdlib.h>, <fbm.h>, or some file that indirectly includes one of them.)  If not, you may be getting bitten by a return-type conversion bug.

Otherwise, check that the "1201" string is really '\0'-terminated.  If there's some other byte at the end of the string, it's possible that the Linux atof is attempting to continue conversion further than it should, while the Sun is stopping at the first non-numeric character.

(I just ran a test program on Linux here; I found that if you don't declare atof(), you get a bogus result, but if you do, you get the correct result -- even if there's a garbage character at the end of the string you convert.)
0
 

Author Comment

by:jshirer
ID: 1292729
Thanks!  There was another byte at the end of the string.  The string was created with the strncpy, not strcpy.  The strncpy on the sun put '/000' as the last byte.  Linux put '9', for whatever reason.  I just had to specify that the last byte = '\0', and it worked!  There are a lot of happy people here now.
0
 
LVL 3

Expert Comment

by:dhm
ID: 1292730
It's unlikely that the strncpy put the "9" there; strncpy copies only as many bytes as you tell it to.  Probably, the buffer you were copying into was uninitialized (i.e. contained garbage), and the garbage on the Sun just happened to be '\0', while on Linux it was '9'.  Gotta watch those memcopy-type functions :-)
0

Featured Post

Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Title # Comments Views Activity
Hibernate methods 2 88
Fibonacci challenge 11 141
Work with App store 7 122
Problem to App source 6 120
Introduction: Load and Save to file, Document-View interaction inside the SDI. Continuing from the second article about sudoku.   Open the project in visual studio. From the class view select CSudokuDoc and double click to open the header …
If you use Adobe Reader X it is possible you can't open OLE PDF documents in the standard. The reason is the 'save box mode' in adobe reader X. Many people think the protected Mode of adobe reader x is only to stop the write access. But this fe…
This video will show you how to get GIT to work in Eclipse.   It will walk you through how to install the EGit plugin in eclipse and how to checkout an existing repository.
Are you ready to implement Active Directory best practices without reading 300+ pages? You're in luck. In this webinar hosted by Skyport Systems, you gain insight into Microsoft's latest comprehensive guide, with tips on the best and easiest way…

738 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question