String to Double Conversion without using strtod() or atof()

[JCasso]

Hi,

I am programming a pos terminal by using C Programming language. I cannot use strtod() or atof (since it just calls strtod in it).

Any advices on converting string to double without using these functions?

Thanks in advance.

[Murtan]

This sounds like an assignment, but you will probably have to re-create what strtod() does.

You will end up validating the string (or characters) and building the number by recognizing the digit characters.

[Ancient Dragon]

use a pointer and convert each digit to binary. Here's how:

char str[] = "123.456";
char* ptr = str;
float n = (*ptr - '0'); // before the decimal point

float n = (*ptr - '0') / 10; // after the decimal point

Now, what I posted above is not a complete program -- I purposely left out important code that will make it work. You also have to have a couple loops and change 10 to a variable that is incremented by 10 on each loop iteration.

[JCasso]

Ancient Dragon,

It seems that it will end up with some function like you proposed. I will wait a few hours more for some possible ideas and mark this as solved.

Thanks again.

[ArkM]

Hi,

I am programming a pos terminal by using C Programming language. I cannot use strtod() or atof (since it just calls strtod in it).

Any advices on converting string to double without using these functions?

Well, use sscanf.
I think it's an incorrect question. Why pos terminal control program can't use strtod? Is it possible to use sscanf? Or you MUST write C-string to double conversion code from the scratch? If so, it's the other story...

[JCasso]

Using strtod causes a segment error, odd but true. About sscanf... Shame on me :) You are right. sscanf can do it.

Well, use sscanf.
I think it's an incorrect question. Why pos terminal control program can't use strtod? Is it possible to use sscanf? Or you MUST write C-string to double conversion code from the scratch? If so, it's the other story...

[Salem]

> Using strtod causes a segment error,
If that's your reason for NOT using it, then you've got bugs in your code. Simply using another function does not make those bugs go away.

All that will happen is that sooner or later, you'll stumble across some other problem. Then, as now, you'll imagine the problem is somewhere else, and ask how to do x without using y.

A simple 5-line program which calls strtod() on your target would prove whether the library for your target was working or not. If the simple test works, and using strtod() in your code doesn't, then you really need to look at your code.

Valid reasons for not using strtod() on a PoS target would be
- too many problems with rounding for numeric values (but that's just floats all over)
- code footprint of the strtod() function is too large.

[ArkM]

I agree with Salem. I have wrote POS terminal control program (some years ago). As usually, no problems with memory and floating point arithmetics on POS processors. Moreover, if strtod is too expensive then sscanf is too expensive, printf is too expensive and so on. Impossible. It's not so time/space consuming code.

[JCasso]

Salem,

I already tried creating a small app which calls strtod. And it failed. Besides, my app works on simulator, I guess this problem is not about my code.

ArkM,

Possibly you've programmed a different brand by using different SDK.

I just defined a double variable, a char array. An called strtod. Works on simulator but not on the device.

Here is the code:

double d;
char s[] = "0.5";
d = strtod(s, NULL);

[ArkM]

Yes, this POS behaves suspiciously ;(
Try not-null endptr argument...
FPU?..

[Salem]

If strtod() works on target with a non-null pointer, then a simple wrapper function would save you an awful lot of re-inventing the wheel.

Oh, and file a bug report with the library maintainer as well. A NULL parameter for the endptr is valid.

[JCasso]

Very well...

After some e-mail traffic with the company, I am shocked with an odd answer. The pos terminal I am working on does not support double or float variable types :S

But I have to use them and I cannot find any solution except re-inventing the wheel. (The one who invented wheel didn't have a deadline I guess :) )

[Salem]

Makes sense really, you don't want floating point anywhere near currency.

If you've got a decimal point to deal with, then consider

dollars = strtoul( p, 10, &endp );
cents = strtoul( endp+1, 10, NULL );
amount = dollars * 100 + cents;

A nice integer, which isn't going to suffer from rounding errors.
So long as you use a 4-byte int thoughout, then overflow isn't likely to be a problem for most reasonable currencies not experiencing hyper inflation.

[JCasso]

Right but it was only that easy if i wouldn't need to use 4 operations ( * / - + ) All except division will not cause much problem I guess.

[ArkM]

Very well...

After some e-mail traffic with the company, I am shocked with an odd answer. The pos terminal I am working on does not support double or float variable types :S

But I have to use them and I cannot find any solution except re-inventing the wheel. (The one who invented wheel didn't have a deadline I guess :) )

Did you remember "FPU?" line in my post above? FPU means "Floating-Point Unit"...
Look at SoftFloat library:
http://www.jhauser.us/arithmetic/SoftFloat.html
Have you any OS on your POS? Sometimes OS supports FP emulation. Old C compilers for MS-DOS, for example, supported emulated floating-points arithmetics.

[JCasso]

I totaly forgat it sorry... Seems like this device does not have it.

About OS... You mean a known one? dont you? No this is a taiwan stuff :(

[ArkM]

My old good POS was from Singapore ;). It was x86 16-bit processor so I have installed DR-DOS. My type Money was unsigned long (32-bit emulation). It's funny but it was CPU with FPU.
Don't worry: the divide op is not the most essential one in POS control program...