Linux atof problem

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.
jshirerAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

dhmCommented:
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

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
jshirerAuthor Commented:
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
dhmCommented:
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
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
System Programming

From novice to tech pro — start learning today.