| Issue 5: | %+2.4lf ++ | |
| 1 person starred this issue and may be notified of changes. | Back to list |
I have no idea what it entails, but I'd adopt it for my embedded project if %+2.4lf (for example) worked - looks like a great lib. Regards, Steve
Aug 2, 2013
Exciting! I'll give it a go...
Aug 16, 2013
Hi Neil!
I'm not the greatest programmer in the world, but I'm getting:
format_fp.c:68:24: error: unknown type name 'T_FormatSpec'
format_fp.c:68:40: error: unknown type name 'VALPARM'
When I try to build format_fp.c
I see those are defined in format.c, which can't be reached in
format_fp.c - how does your compiler find the definition when building
format_fp??? I doesn't seem to appear in any of the headers.
Also:
#ifdef __cplusplus
extern "C" {
#endif
...
#ifdef __cplusplus
};
#endif
Would not be a bad idea around format.h declarations, either?
When I hack all the definitions out of format.c into format.h (making
it incompatible with the svn repo), given this:
double test = 1.23456789;
float test1 = 1.23456789;
::outf("%lf\n", test);
::outf("%lf\n", test1);
I get this:
2730582081536.012000
2.000000
I'm on an Arm7 (NXP LPC2148), btw. What memory space does format use
for f/p conversions? Newlib uses malloc which is my main reason for
trying to use format instead.
Thanks again,
Steve
Aug 16, 2013
Looks like it's a local on the stack, no? Steve
Aug 16, 2013
Strangely, I get the same thing with printf. My compiler is really broken, I guess. Disregard that one. Steve
Aug 16, 2013
Hi format_fp.c is #included into format.c so you do not need to "build" it - see the testharness makefile. I'm not going to add support for C++ because it is a very different language from C in numerous subtle ways. The format library is C only - if you can get it to work with C++ then good for you. Format uses only stack space. It does not use any malloced memory. So it probably won't be as fast as newlib which does all sorts of buffering and whatnot. I guess you could do that in your consumer function if you wish. Neil
Aug 16, 2013
Also note that the 'l' length modifier has no effect on the floating point conversions - it is silently ignored. The only one that might is 'L' signifying a long double as stated in the C spec. The current version of format will return an error if you use it.
Aug 16, 2013
k, that's fine, thanks. I guess I can just wrap the include statement itself in extern C.
Aug 16, 2013
Depending on which flavour of ARM and which flavour of float support you have format might have trouble unpacking double values. From what I can see there are three possible ARM floating point layouts - little endian, natural endian (could be big or little), or a weird mixed mode used by the early FPA.
Aug 16, 2013
I've never seen it be anything but l/e in practice. Earlier versions of arm-elf gcc (I'm on arm-none-eabi gcc now) actually swapped the two 32b halves of a double internally (4-3-2-1-8-7-6-5), that was unpleasant when handling wire protocols! It's sane-er now (8-7-6-5-4-3-2-1). Just wraping the #include in extern "C" makes it all build just fine right out of the repo, btw. Didn't realize fp.c was an include file. That's oldskool. Thanks for getting me up & running.
Aug 19, 2013
If you're printing out real-world data try the new `!` flag for your `f` conversions.
Oct 23, 2013
Support for most floating point formatting now implemented.
Status:
Fixed
|
Owner: neil.johnson71