RE: Converting Float type data to String 06-12-2014, 02:11 AM
#7
I see magic numbers here:
Which should be: (including <limits.h>)
And instead of using memcpy after the fact, I would've used calloc():
sizeof(char) is guaranteed to be 1 anyways, so using the sizeof() operator is redundant.
The other stupid thing about that code is that they only allocate 32 bytes... (What about -> float f = 1.9876E+38; ??) Assuming that the digits, including the decimal within that floating point number, stay within the allocated space, hence potential for buffer overflow. However, this won't work:
Precision in the conversion to a c-style string is lost.
In that code though, I have no clue why the person used memcpy() to zero out the memory block, then proceed to add a null terminator anyways at the end:
Kind of redundant wouldn't you think? Although, this would make sense and be only useful if the allocated space was overflowed, in which case, the end null terminator is lost anyways, and buffer overflows are not good. If he's going to manually write the null terminator, why did he even bother with using memcpy() to write a bunch of '\0's to that allocated memory block?
IMHO, that is no code to learn from.
To do this properly, I think the best thing to do would be to parse the bytes manually and look at each segment of bits within that numeric value based on the IEEE 754 standard. Parse out the sign, exponent, and mantissa manually, and use that to determine the string.
Code:
fstr = malloc( 32 * sizeof( char ) );
memcpy( fstr, "0", 32 );Which should be: (including <limits.h>)
Code:
fstr = malloc( sizeof(num) * CHAR_BIT * sizeof( char ) );
memcpy( fstr, "0", sizeof(num) );And instead of using memcpy after the fact, I would've used calloc():
Code:
fstr = calloc(sizeof(num) * CHAR_BIT , 1);sizeof(char) is guaranteed to be 1 anyways, so using the sizeof() operator is redundant.
The other stupid thing about that code is that they only allocate 32 bytes... (What about -> float f = 1.9876E+38; ??) Assuming that the digits, including the decimal within that floating point number, stay within the allocated space, hence potential for buffer overflow. However, this won't work:
Code:
float f = 128038.329;
char *s = ftoa( f );
printf( "%f\n", f );
printf( "%s\n", s );Precision in the conversion to a c-style string is lost.
In that code though, I have no clue why the person used memcpy() to zero out the memory block, then proceed to add a null terminator anyways at the end:
Code:
*(fstr) = '\0';Kind of redundant wouldn't you think? Although, this would make sense and be only useful if the allocated space was overflowed, in which case, the end null terminator is lost anyways, and buffer overflows are not good. If he's going to manually write the null terminator, why did he even bother with using memcpy() to write a bunch of '\0's to that allocated memory block?
IMHO, that is no code to learn from.
To do this properly, I think the best thing to do would be to parse the bytes manually and look at each segment of bits within that numeric value based on the IEEE 754 standard. Parse out the sign, exponent, and mantissa manually, and use that to determine the string.
ArkPhaze
"Object oriented way to get rich? Inheritance"
Getting Started: C/C++ | Common Mistakes
[ Assembly / C++ / .NET / Haskell / J Programmer ]
"Object oriented way to get rich? Inheritance"
Getting Started: C/C++ | Common Mistakes
[ Assembly / C++ / .NET / Haskell / J Programmer ]
![[+]](https://sinister.ly/images/modern/collapse_collapsed.png)