-2

Having trouble C language debug step into process decimal point operator in a floating point sting of numbers. Example: 1234.5678, itoa() output stops at 4 and terminates out array string with '\0' Null char* pointer also an array. So we only get 1234\0 in the out array even after adding test for '.' seems to just skip over it like it's not really there. Thanks for any ideas to get these counts and floating-point decimal point for serial UART data without using printf().

Also strnlen() has same issue, counts only to the decimal point and C sizeof returns the count of 2 (1234.5678) characters are put in the array1={0.0} yet sizeof operator is in violation of clang definition below since it only returns count of 2 for the string. This may be vendor related string.h

#if defined(_INLINE) || defined(_STRLEN)
_OPT_IDEFN size_t strlen(const char *string)
{
   size_t      n = (size_t)-1;
   const char *s = string;

   do n++; while (*s++);
   return n;
}
#endif /* _INLINE || _STRLEN */

size_t len = sizeof *varin;

sizeof object and sizeof(type name): yield an integer equal to the size of the specified object or type in bytes. (Strictly, sizeof produces an unsigned integer value whose type, size_ t, is defined in the header <stddef. h>.) An object can be a variable or array or structure. A type name can be the name of a basic type like int or double, or a derived type like a structure or a pointer.

```
/*****************************************************
*
*! Implementation of itoa()
*
* b\return converted character string
*
***************************************************/
char*
itoa(int16_t num, char* str, int base)//intmax_t
{
    uintptr_t  i = 0; //int 
    bool isNegative = false;

    /* Handle decimal point explicitely with ASCII (".")  */
    if(num == '.')
    {
        //str[i++] = '.';
        str[i] = 0x2E;
       //
        return str;
    }

    /* Handle unterminated end of string by adding NULL */
    else if(num == ' ')
    {
       str[i] = '\0';
       //
        return str;
    }

    /* Handle 0 explicitely, otherwise Null string is printed for 0 */
    if(num == '0') //0
    {
        str[i++] = '0';
        //str[i] = '\0';
        return str;
    }

    // In standard itoa(), negative numbers are handled only with
    // base 10. Otherwise numbers are considered unsigned.
    if (num < 0 && base == 10)
    {
        isNegative = true;
        num = -num;
    }

    // Process individual digits
    while (num != 0)
    {
        int16_t rem = num % base; //intmax_t
        str[i++] = (rem > 9)? (rem-10) + 'a' : rem + '0'; //
        num = num/base;
    }


    // If number is negative, append '-'
    if (isNegative)
    {
        str[i++] = '-';
    }

    // Append string terminator
    str[i] = '\0';

    // Reverse the string
    reverse(str, i);

    return str;
}
```
/* Decls */
static float32_t varin[1] = {0.0};
*varin = dbytes;
static char varout[8];

/* Convert hexadecimal to ASCII codes
 * terminate end NULL */
itoa(*varin, varout, 10);

Debug of the in/out arrays sent to itoa()

  • 2
    Your `itoa` function looks like it will mostly succeed at converting an integer to a string, which is indeed `itoa`'s job. But you cannot store a floating-point number like `1234.5678` in an integer! It's one of the defining characteristics of an integer that there cannot be a fractional part. The `.5678` part is being lost when you try to pass/assign that floating-point number as an `int`, not due to any bug in your `itoa` code. – Steve Summit Dec 28 '22 at 01:55
  • 2
    Some tips: (1) Get rid of the test for `num == '.'`. It's quite meaningless, and will serve only to prevent you from properly converting the integer 46. (2) Get rid of the test for `num == ' '`, which is also meaningless. (3) Put back the commented-out `str[i] = '\0';` lines; you do need them. (4) If you use a `do`/`while` loop, you can get rid of the test for `num == 0`. – Steve Summit Dec 28 '22 at 01:59
  • Hey all I added the debug output link and strln() call and decals to both itoa() arrays. The debug link (above) seems to infer the compiler is not adding a space char, rather '\0' for the floating decimal point. There is no reason for doing that in my opinion. Outdated and proper handling of integer type FPU data seems more suspect looking at debug link. And itoa can easily handle a space in the input array but will only handle NULL in as NULL out. The compiler NULL's the decimal point, not passing it into the input array string as shown in the debug output link ;-) – user20874661 Dec 28 '22 at 15:07
  • Thank you for the additional code, but again: *You cannot convert floating-point numbers with this code.* It makes no sense. Also I'm not sure what you mean by "input array". The input to your `itoa` function is an *integer*, not an array. It contains no characters — space, decimal point, or otherwise. – Steve Summit Dec 28 '22 at 16:28
  • Please compile and run this code: `char varout[20]; float f = 123.456; int i = f; printf("f = %.3f, i = %d\n", f, i); itoa(f, varout, 10); printf("%s\n", varout); itoa(i, varout, 10); printf("%s\n", varout);` This should hopefully give you some hints about what's actually going on. – Steve Summit Dec 28 '22 at 16:41
  • So you know: an `int` (or `int32_t`) value like `123` is **not** stored internally as the digits `'1'`, `'2'`, and `'3'`. And a floating-point value like `123.456` is *very* much **not** stored as digits with a `'.'` character in the middle. (If they were stored this way, we wouldn't need functions like `itoa` to generate printable string representations.) – Steve Summit Dec 28 '22 at 17:41
  • @Steve Summit A lot of how not to solve this, how about more focus on sol'n(s)??? – Andrew Dec 29 '22 at 13:51
  • We only use itoa to convert 2's complements integers to ASCII. And printf() suffers the same issue being tied to incorrect floating point decimal point behavior of IEEE FP precision standard. This is nothing more than lazy compiler programming using the dot operator to represent the decimal point in floating point integer strings. The ASCII dot (0x2E) is decimal 46 for more than 40 years or more. – user20874661 Dec 30 '22 at 13:48
  • @user20874661 "In standard itoa(), negative numbers are handled only with // base 10." is amiss. `itoa()` is **not** part of the C standard library. Perhaps you are referring to some implementation's specific library, in which case, that library is not standard C. The details of `itoa()` in various library extensions vary. – chux - Reinstate Monica Dec 30 '22 at 14:08
  • Steve the Itoa() input string was being set, array[1] = {0.0}. I had no idea the dot was C operator and not an actual floating decimal point being the FPU processed the integers by float directive. All integers 0-9 are also hexadecimal numbers and stored that way in two's complement binary. Monica there was no Itoa() in C lib being deprecated some time ago. Thank you for posting the nice converter above but I need the decimal point for the HID number widgets since the Xfloat widgets only handle 8 points ± deep. – user20874661 Jan 03 '23 at 20:44

4 Answers4

1

float to text is easy to do - with poor results.
float to text is hard to do - with good results.

Here are some of the issues:

  • Is the destination char[] big enough?

  • Does conversion handle extreme values, Not-a-number, Infinity, -0.0, sub-normals? If not, what is the range limit?

  • Is the result rounded? What rules used to round?

  • How good is the conversion? How close to the best possible answer?


I took OP's over-all goal and had to morph it a bit to form a reasonable function.

Use |f| up front to use unsigned math.

I scaled the float and then converted to an integer, wider the better. unsigned __int128 is a compiler extension, else use uintmax_t and expect reduced conversion range and reduced ftoa_PREC_MAX. Extra scaling (by 2) allows for a simple rounding.

When the float is large, no scaling needed as the fraction is 0.

Modestly tested code went well with the resulting text within the converted text of f +/-1 ULP.
Better code would be within 0.5 ULP. Edge cases not well exercised.

#include <float.h>
#include <math.h>
#include <stdbool.h>
#include <stddef.h>
#include <string.h>

#include <stdio.h>

#define ftoa_PREC_MAX 15
typedef unsigned __int128 uint_wide;  // At least 32 bit
// UINT_WIDE_MAX is the greatest convertible value.
#define UINT_WIDE_MAX_PLUS1 ((-(uint_wide)1 / 2 + 1)*2.0f)

// Convert `float` to a string.  Return NULL on error.
char* ftoa(size_t sz, char dest[sz], float f, unsigned prec) {
  // Check for pathological parameters.
  if (sz == 0 || dest == NULL) {
    return NULL;
  }
  dest[0] = '\0';  // Pre-set dest to "" for error cases.

  // First form result in an ample buffer.
  //       -       i digits           .   f digits       \0
  char buf[1 + (FLT_MAX_10_EXP + 1) + 1 + ftoa_PREC_MAX + 1];
  char *p = buf + sizeof buf;
  *--p = '\0';
  bool sign = signbit(f);
  if (sign) {
    f = -f;
  }

  // Test for more extreme values.
  if (!isfinite(f)) {
    return NULL;
  }
  if (prec > ftoa_PREC_MAX) {
    return NULL;
  }
  if (f >= UINT_WIDE_MAX_PLUS1) {
    return NULL;
  }

  // Determine fraction.
  uint_wide u;
  // If f is large enough, its fractional portion is .000...000.
  // No need to scale and potentially overflow. 
  if (f > 1.0f / FLT_EPSILON) {
    u = (uint_wide) f;
    for (; prec > 0; prec--) {
      *--p = '0';
    }
  } else {
    // Scale by power-of-10 (could use a look-up table instead) and 2.
    u = (uint_wide) (f * powf(10, (float) prec) * 2);
    // Round, ties up.
    u = (u + 1) / 2;  
    for (; prec > 0; prec--) {
      *--p = (char) (u % 10 + '0');
      u /= 10;
    }
  }
  *--p = '.';
  
  // Determine whole number part.
  do {
    *--p = (char) (u % 10 + '0');
    u /= 10;
  } while (u);
  if (sign) {
    *--p = '-';
  }
  
  // Copy to destination.
  size_t len = (size_t) (buf + sizeof buf - p);
  if (len > sz) {
    return NULL;
  }
  return strcpy(dest, p);
}

The source of errors include f * powf(10, (float) prec) as the power-of-10 is approximate when prec > 9 and the multiplication may incur rounding. A more advanced solution would use wider FP math.

chux - Reinstate Monica
  • 143,097
  • 13
  • 135
  • 256
  • @user20874661 Where is the `int2string()` code? – chux - Reinstate Monica Jan 05 '23 at 00:54
  • @Monica, Andrew posted it just below your latest posted code. – user20874661 Jan 05 '23 at 01:06
  • Note the fdtoa() below used a fast RTS call to powf() the complier used double and separated the float32 input at the C operator dot. That was another issue to get strlen() to return the length of the string right of the dot. The output cannot use printf() to format the string as inline call sends UART TXD a HID command then the data to the target widget. – user20874661 Jan 05 '23 at 01:17
  • These compiler switches stop C2000 MCU powf() errors: --float_operations_allowed=all thought that was supposed to be the default mode. • If --tmu_support=tmu1 is used with --fp_mode=relaxed, special "relaxed" versions of the following 32-bit RTS math functions are used: exp2f(), expf(), log2f(), logf(), and powf(). Note that relaxed versions that work with double types are not provided – user20874661 Jan 05 '23 at 01:27
1

I think there are three separate problems here. Let's cover them in turn.

C sizeof returns the count of 2 characters are put in the array

sizeof is for computing the size of an object as declared. It's not generally any good for determining the length of a string. I suspect you got 2 because you (a) tried to take the size of a pointer and (b) are using a 16-bit microcontroller. You can demonstrate that issue like this:

char *p = "Hello, world!";
printf("size of pointer: %d\n", (int)(sizeof(p)));
printf("length of string: %d\n", (int)(strlen(p)));

sizeof computes the size of the pointer itself, while strlen computes the length of the pointed-to string.

The second problem is that you seem to be imagining that a number — an int or float value — contains human-readable characters like '.' or ' ' or '0'. It does not. A number is a number you can do math on; it is not a string of characters you can see. In your itoa implementation, you're doing things like

if(num == '.')

and

if(num == ' ')

and

if(num == '0')

But these are all wrong. If an integer has the value 0, it does not contain the character '0'. A floating-point variable like float f = 123.456 looks to you and me like it contains a decimal point, but in the computer's memory, it does not, so it makes no sense to test whether num is equal to '.'. (It makes especially no sense since num in that code is an integer variable, not a floating-point variable.)

The third problem is that you're trying to use your itoa function to directly convert a floating-point value, and it's failing, and you're surprised at the way it's failing. But really, there's no surprise. If you have a function

char * itoa(int16_t num, char* str, int base);

that accepts an integer parameter num, and you pass a floating-point value like 123.456, the first thing the compiler is going to do is convert the floating-point number to an integer, by throwing away the fractional part. That's why everything after the decimal point seems to be missing.


So with those misconceptions out of the way, let's look at how to properly convert a floating-point number to its string representation. It turns out this is a very hard problem! In fact, a proper algorithm for performing this task, in all cases, without error, was not published until 1990. So the right way to convert a floating-point number to a string is generally to use printf or sprintf, because those functions have a pretty good chance of using a proper algorithm.

But you said you didn't want to use printf. It's possible to convert a floating-point number to a string "by hand" — it can actually be rather straightforward — but you should realize that any code you can write will probably not do a perfect job of it.

You can find some code and commentary about this problem at this former SO question and also this one.

Here is a simple, straightforward, basically simpleminded ftoa function for converting floating-point numbers to strings. It's written on top of your existing itoa function, as I think you were trying to do. It follows the approach suggested in this comment: it takes a floating-point number like 123.456 and breaks it up into an integer part 123 and a fractional part .456. It converts the integer part using itoa. Then it converts and appends the fractional part by repeatedly multiplying it by 10. It accepts a maxprec argument telling it how many digits after the decimal to print, just like the number you can use in %.6f in printf.

char *ftoa(float num, char buf[], int bufsize, int maxprec)
{
    char *p = buf;

    /* handle negative numbers */
    if(num < 0) {
        *p++ = '-';
        num = -num;
    }

    /* extract and convert integer part */
    int ipart = num;
    itoa(num, p, 10);

    /* extract and convert fractional part */
    float fpart = num - ipart;
    p += strlen(p);
    *p++ = '.';
    int ndig = 0;
    char *endp = buf + bufsize - 1;     /* leave room for \0 */

    /* keep going as long as (a) there's some fractional part left and */
    /* (b) we haven't converted too many digits and */
    /* (c) we haven't overflowed the destination buffer */
    while(fpart != 0 && ndig < maxprec && p < endp) {
        fpart *= 10;
        int digit = fpart;
        *p++ = digit + '0';
        fpart = fpart - digit;
        ndig++;
    }

    /* null-terminate and return final string */
    *p = '\0';
    return buf;
}

Here is an example call:

char buf[20];
printf("%s\n", ftoa(123.456, buf, sizeof(buf), 6));

But please note that this is not a very good function! It will work decently well for "simple" floating-point numbers, but it has plenty of problems. The example call ftoa(123.456, buf, sizeof(buf), 6) shows one of them: it converts to 123.456001 on my machine. (Although, that's not actually as wrong as it looks.)

As mentioned, properly converting floating-point numbers to strings is a very hard problem, and this simpleminded code does not attempt to address any of the hard parts of the problem. See chux's answer for a somewhat more complete approach.

Also, for this to work at all you're going to have to fix at least some of the problems in the underlying itoa function. At the very least, change if(num == '0') to if(num == 0) and uncomment the str[i] = '\0' line in that case. You should also get rid of the num == ' ' and num == '.' cases, which you don't need and which will cause unnecessary problems trying to convert the numbers 32 and 46.

Steve Summit
  • 45,437
  • 7
  • 70
  • 103
  • According to my C lang manual sizeof() should return the number of integers in an Array but actually returns the number of hexadecimal characters up to the dot in float. It flawlessly works to check the number of key elements in a struct. And strlen() has the same kind of float issue but actually returns the number of integers up to the dot. – user20874661 Jan 03 '23 at 20:59
  • while(fpart != 0 && ndig < maxprec && p < endp) {~~~~~~~~~~~~~~~} The problem is the compiler will not convert Itoa() non-floating parts of the expression as C language defines it should be doing without generating linking errors. I posted this very issue in the TI C2000 forum. Even if we make the equation values x.x still does not convert the integers of both numerators to be same type. Also can't fprint() to a UART FIFO being ftoa() is inline needs to convert hex via base 10 to ASCII hex digits. – user20874661 Jan 03 '23 at 21:34
  • @user20874661 Did you try the code that I posted? – Steve Summit Jan 03 '23 at 22:44
  • @user20874661 `sizeof` does not return "the number of integers in an array". It returns the size, in bytes, of any data object. Applied to a `float` object, `sizeof` does not return "the number of hexadecimal characters up to the dot", it returns 4, on most systems. (There is no dot in a `float`.) It is equally meaningless to apply `strlen` to a `float`: `strlen` is exclusively for strings, not objects of other data types. `strlen` cannot return "the number of integers up to the dot", because again, there are no integers, characters, or dots in a `float` value. – Steve Summit Jan 03 '23 at 22:53
  • @user20874661 *it should be doing without generating linking errors* Please post the text of those errors, along with the code that generates them. – Steve Summit Jan 03 '23 at 22:54
-1

As discussed, there are many issues with your approach. I would punt completely if I were you. Here is a possible approach that might work better. Refer to https://www.geeksforgeeks.org/convert-floating-point-number-string/

Mac_3.2.57$cat asciToFloat.c
// C program for implementation of ftoa()
#include <math.h>
#include <stdio.h>
 
// Reverses a string 'str' of length 'len'
void reverse(char* str, int len)
{
    int i = 0, j = len - 1, temp;
    while (i < j) {
        temp = str[i];
        str[i] = str[j];
        str[j] = temp;
        i++;
        j--;
    }
}
 
// Converts a given integer x to string str[].
// d is the number of digits required in the output.
// If d is more than the number of digits in x,
// then 0s are added at the beginning.
int intToStr(int x, char str[], int d)
{
    int i = 0;
    while (x) {
        str[i++] = (x % 10) + '0';
        x = x / 10;
    }
 
    // If number of digits required is more, then
    // add 0s at the beginning
    while (i < d)
        str[i++] = '0';
 
    reverse(str, i);
    str[i] = '\0';
    return i;
}
 
// Converts a floating-point/double number to a string.
void ftoa(float n, char* res, int afterpoint)
{
    // Extract integer part
    int ipart = (int)n;
 
    // Extract floating part
    float fpart = n - (float)ipart;
 
    // convert integer part to string
    int i = intToStr(ipart, res, 0);
 
    // check for display option after point
    if (afterpoint != 0) {
        res[i] = '.'; // add dot
 
        // Get the value of fraction part upto given no.
        // of points after dot. The third parameter
        // is needed to handle cases like 233.007
        fpart = fpart * pow(10, afterpoint);
 
        intToStr((int)fpart, res + i + 1, afterpoint);
    }
}
 
// Driver program to test above function
int main()
{
    char res[20];
    float n = 233.5;
    ftoa(n, res, 1);
    printf("\"%s\"\n", res);
    return 0;
}
Mac_3.2.57$cc asciToFloat.c
Mac_3.2.57$./a.out 
"233.5"
Mac_3.2.57$
Andrew
  • 1
  • 4
  • 19
  • `int ipart = (int)n;` and so `intToStr(ipart, res, 0)` fail when `n` not near the `int` range. Consider `float modff(float value, float *iptr);` to break a `float` into integer and fraction parts. – chux - Reinstate Monica Dec 30 '22 at 14:27
  • `fpart = fpart * pow(10, afterpoint); intToStr((int)fpart, res + i + 1, afterpoint);` is a problem when `fpart * pow(10, afterpoint)` returns a round-up to the power of 10 value. Consider `float n = 233.999; ftoa(n, res, 1);`. – chux - Reinstate Monica Dec 30 '22 at 14:35
  • @ makes sense; Also: n = 233.4, will return n = 233.3--hashing-out the details of this bug is left as an exercise for the OP. "might" work better is what i said ;-) – Andrew Dec 30 '22 at 14:37
  • On review, `fpart = fpart * pow(10, afterpoint)` is unlikely to experience the [round-up](https://stackoverflow.com/questions/74934003/modify-itoa-to-process-a-floating-point-string-with-decimal-point-operator-into/74951935?noredirect=1#comment132285298_74951935) suggested as the multiplication is done with `double` math. – chux - Reinstate Monica Dec 30 '22 at 14:54
  • The entire problem is the char* string has to be written to handle a floating-point integer string with an invisible operator dot. The char* does not read to right of the operator dot and there is no type conversion by the compiler of decimal integrals tests to match float. After all it's a floating decimal point FPU math, not floating operator FPU math. – user20874661 Dec 30 '22 at 16:33
  • Wonder if C++ has the same issue, compiler not doing proper decimal point placement with (ASCII 0x23 . dp) decimal/integer 46. Why would the FPU inside the CPU be using a C operator is the bigger question rather than simply using decimal point as it should. The itoa as it was written was a oneway ticket for strnlen() to UART TXD but the HID also modifies the FP string, sends it back to the UART RXD host side. Suppose the quick WA might use above string code but it has to use float* out with decimal point (0x23) or it will never work for Xfloat HID widgets. – user20874661 Dec 30 '22 at 16:56
  • @user20874661 Please post code demonstrating your compiler's alleged "not doing proper decimal point placement". – Steve Summit Dec 31 '22 at 04:33
  • sounds unlikely – Andrew Dec 31 '22 at 11:51
  • @user20874661 There is no such thing as a "floating-point integer string with an invisible operator dot". – Steve Summit Dec 31 '22 at 15:26
  • Mac_3.2.57$cat asciToFloat.c , Thanks Andrew that code piece will come in handy for handling ASCII RDX integers with decimal point 0x23 from the UART. I had thought Monica posted that code, now see your avatar below it. Most all the applications floats begin like 0.12345. I had to do inline exponential multiplication to move the C dot and it did that only to the extent of float64_t prior to overflowing. A quick solution to move dot only few places right as it turns out/ – user20874661 Jan 04 '23 at 18:23
  • Steve, I tested your code piece and thank you for efforts though it was changing the input values all the same output. My Itoa() uses letter "a" to convert integers into ASCII output for the HID widgets + commands. Also tried base 16 and 2 in your codes call to itoa(), removed the null that itoa appends and still got the same results. As for your other itoa() comments I had removed all those tests for '.' etc, since the UART first calls it to convert integers to send inline ASCII "commands" to the HID. – user20874661 Jan 04 '23 at 18:31
  • Steve said: "There is no such thing as a "floating-point integer string with an invisible operator dot". Did you check out the debug link that replaced the input array[] buffer dot with nulls in the output array[]. I was initially trying to capture the C dot as ASCII dot 0x23. Seems the debug C code simulator preprocessed the input array to Itoa even before stepping into it, the output array buffer appears missing the C dot. You mentioned the int does that so good point there. – user20874661 Jan 04 '23 at 18:40
  • Sadly, the same issue occurs in both solutions posted. Though fdtoa() can replace '.' with ' ' as 0x23 space character. Yet the int2string is not returning any useful data to itoa(). The 0's right of dot decimal place holder are required not to be removed. So 0003267895 could be the output TXD and the xfloat widget set to 0.0. Sending hot characters out UART FIFO does not use printf() to format the TXD string. – user20874661 Jan 05 '23 at 01:07
  • The int2string() is returning only ( i ) without the char string. I renamed double to string fdtoa() though it stops at the dot but split the float in 2 halves at the dot. Set a compiler switch to accept doubles for 32-bit FPU eabi lib powf() processing stopped the errors. Will post debug links above if allowed. The input to fdtoa() was split by float64 exponent multiplication and not representative, most every TXD float32 are 0.123456789-12 deep. So it should be even easier for int2string() if it returns the processed string – user20874661 Jan 05 '23 at 01:08
  • @Andrew the largest strings are all (float32) most no deeper than -12 char right of '.' . Yet strlen() used only the decimal char 0x32 in 3 then 2 (space) with strlen() 2 length and skipped all 0's to right of space replacing the dot int2string. Very impressed it could do that. I modified the !0 as if(afterpoint) { res[i] = ' ' so the 0's would be included such as (000612712456) would be the result but decimal 23 could be used in itoa() for number widget to print 0.000612712456. What do you think? – user20874661 Jan 05 '23 at 01:41
  • The closest exactly representable 32bit float to 0.12345 is 0.123450003564357757568359375. – Andrew Jan 05 '23 at 11:06
  • I think the reverse part has an issue and would not work with my itoa(). I use reverse with separate swap function. Oddly the one above worked for "commands" part but not for sending integers via atoa() ASCII with or without the dot. Though your code can replace the dot with decimal 46 and only tested space ' ' and "0x23" last night. The preceding zeros, e.g. (0.000612456783) should not be removed if possible. The vendor compiler has restricted sprintf() only returns output integer count, no formatting is allowed. – user20874661 Jan 05 '23 at 15:55
-1

The problem is C in this MCU compiler believes the decimal point of FP integer string is an operator. If that is how Borland saw the world 30++ years ago for base 10 before FPU existed perhaps it was the only way to express a decimal point. I found this out by trying to create an (enum) list with floating point values tied to exported variables of the same name. Anyway a decimal point of FPU base 10 string is NOT an C/C++ operator! Seems the C language does not account correctly for decimal points in IEEE FPU specification for base 10 integer strings.

  • 2
    Can you provide any evidence that the "compiler believes the decimal point of FP integer string is an operator"? I know there have been some weird compilers over the years, but I'm having a hard time believing this. – Steve Summit Dec 31 '22 at 15:27
  • That is how C language defines the dot as an operator of many. The dot can also be used to form compound variables with a tag key of a struct name. Yet when (float) precedes any number of integers with a dot somewhere inline it should automatically format the operator dot as ASCII period 0x23 for the FPU. Assembler trace show ALU is being invoked after (float) directive with FPU call tag. C language MCU's need special compiler handling. No need for ALU involvement passing float strings as integers. The decimal point is ASCII decimal 46 detected by a single itoa() test. – user20874661 Jan 03 '23 at 21:12