Solved

Mystery: atof() terminating program?

Posted on 2003-10-27
9
411 Views
Last Modified: 2010-04-15
Hello,

Please can you help me with a problem with the atof() function.  I am calling this function from an MS-DOS application, and it appears to be terminating the application and exiting to the DOS prompt (with errorlevel 0).  The application is approx 1000 lines of code.

I have tried creating a "test function" to investigate the problem:

  void test_atof() {
     double d;
     printf("\nbefore");
     d = atof("1.1");
     printf("\nafter: '%f'",d); getch();
  }

This test function works perfectly when called from a stand-alone test harness.

However, when called from anywhere in the application, this test function is terminating the application?

Have you experienced, or are you aware of any problems with the atof() function?  How can I solve this problem?

Thanks,
James
0
Comment
Question by:James20000
  • 4
  • 4
9 Comments
 
LVL 8

Expert Comment

by:Exceter
ID: 9626934
>> This test function works perfectly when called from a stand-alone test harness.

It should.

>> However, when called from anywhere in the application, this test function is terminating the application?

You're saying that that EXACT function, when called from your app, will display "before" and then your application terminates? Does the application terminate if you don't use atof? What OS and compiler are you using? Have you included math.h and or stdlib.h?

Are you getting any errors when the program terminates? Access violations or segmentation faults? Are you using this function in a different context in your app? If so, that might have something to do with it.

Exceter
0
 
LVL 45

Expert Comment

by:Kdo
ID: 9627267

Hi James20000,

My guess is that your program is clobberring part of your code section.

Link the code and generate a loadmap.  Look to see what items are loaded immediately BEFORE the atof() function.  Just before you execute the call to atof() that aborts the program, insert a call to the function immeditately BEFORE atof().  If it aborts too, move up another function.  Keep doing this until you find a function that doesn't abort.

What you'll probably find is that the function that doesn't abort contains a buffer overrun and is copying data over the top of executable code.


Good Luck!  These can be a pain to track down.

Kent
0
 

Author Comment

by:James20000
ID: 9627316
Exceter,

Correct.  If I call that EXACT function from my app, it displays "before" and then terminates to DOS prompt.  Even if it's the FIRST statement in main().

I am including <stdlib.h>.  I have tried with and without <math.h>, which makes to difference.  The compiler is Microsoft Visual C++ version 1.52, and the OS is Datalight ROM-DOS version 6.22.  (80386 processor).

However, if I don't use atof, then I get a different result entirely....

  void test_atof() {
     double d;
     printf("\nbefore");
     d = 123.456;  //atof("1.1");
     printf("\nafter: '%f'",d); getch();
  }

If I call this from the stand-alone test harness, then it works as expected:

  before
  after: '123.456000'

If I call this exact function from the app, then it displays:

  before
  after: '0.000000'

It appears to be failing to store or recall the double?
0
 

Author Comment

by:James20000
ID: 9627613
Kdo,

I have looked through the loadmap (see snippet below) :

  0235:2194       _strncpy
  0235:21BE       _atoi
  0235:21C2       _atol
  0235:21C6       _atof
  0235:221E       __catox
  0235:2274       __itoa
  0235:2290       __fptostr

I have modified my test function to call atol() immeditately before atof() :

  void test_atof() {
     long l;
     double d;
     printf("\nbefore");
     l = atol("98765");
     printf("\nafter: '%li'",l);
     d = atof("1.1");
     printf("\nafter: '%f'",d); getch();
  }

The call to atol() runs and returns correctly.  The call to atof() terminates application?

James
0
What Should I Do With This Threat Intelligence?

Are you wondering if you actually need threat intelligence? The answer is yes. We explain the basics for creating useful threat intelligence.

 
LVL 45

Accepted Solution

by:
Kdo earned 300 total points
ID: 9627790

Two more things to check:

Some old DOS compilers dynamically linked certain floating point routines based on the compiler "discovering" that floating point operations were in use.  The compilers were pretty dumb about it, not linking all of the modules when floating point APIs were called or floating point display (printf ("%f", FValue);) was invoked.  Try inserting explicit floating point math in the program prior to calling atof().

/*  Global Variables  */

double D1 = 1.3;
double D2 = 3.141;
double D3;

/*  Anywhere in the program  */

  D3 = D1 * D2;


Check your compiler options with regard to floating point instructions.  You might be using the "use floating point instructions" option when your machine doesn't have them and the instructions need to be emulated.  (This should apply only if you've got a very old PC.)


Kent
0
 

Author Comment

by:James20000
ID: 9628469
Kent,

Thanks for the help and for suggesting looking at floating point operations.

I did eventually solve the problem.  One of the library files I was using (TCP/IP socket handling) was completely knocking out all F.P. ops!   Don't know why yet, (waiting for response from library developer).

Fortunately I've got an older version of the lib, which may be older but atleast it doesn't knock out FP!

James
0
 
LVL 45

Expert Comment

by:Kdo
ID: 9629184

Glad to help.

I'm completely bewildered about why (and how) the socket library is knocking out floating point operations.  There must be more involved than just this.

Does the socket library have it's own atof() function?


Kent
0
 

Author Comment

by:James20000
ID: 9629393
No.  It's deeper than just atof().  When I added your three global variables and added `D3 = D1 * D2`, that too terminated the app!

And if I tried adding `printf("%f",123.456)`, that was displaying a result of "0.000000"

Something seriously not right somewhere!

What I do have, in the app global declarations, is a line which reads `C_SOCKET socket1` (which calls the constructor of C_SOCKET class).  This seems to be the FP killer.

James
0
 
LVL 45

Expert Comment

by:Kdo
ID: 9633133

Check the source code for C_SOCKET and any items from which it may be derived.

I wonder if a well-intended #pragma statement is still in effect that has disabled floating point operations.


Kent
0

Featured Post

How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

Join & Write a Comment

This tutorial is posted by Aaron Wojnowski, administrator at SDKExpert.net.  To view more iPhone tutorials, visit www.sdkexpert.net. This is a very simple tutorial on finding the user's current location easily. In this tutorial, you will learn ho…
This is a short and sweet, but (hopefully) to the point article. There seems to be some fundamental misunderstanding about the function prototype for the "main" function in C and C++, more specifically what type this function should return. I see so…
Video by: Grant
The goal of this video is to provide viewers with basic examples to understand and use while-loops in the C programming language.
The goal of this video is to provide viewers with basic examples to understand opening and reading files in the C programming language.

760 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

Need Help in Real-Time?

Connect with top rated Experts

21 Experts available now in Live!

Get 1:1 Help Now