My favorites | Sign in
Project Home Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
  Advanced search   Search tips   Subscriptions
Issue 5: %+2.4lf ++
1 person starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  neil.johnson71
Closed:  Oct 2013


 
Reported by bahamasf...@gmail.com, Aug 20, 2012
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
Project Member #1 neil.johnson71
Hi Steve,
I have added support for most of the functionality of the decimal floating point formats (e,f,g), so your example should work, other than 'l' has no effect on the 'f' conversion (the only valid one is 'L' for long double and that isn't supported yet).  You can certainly do "%+2.4f" which should do what you want.
Neil
Status: Accepted
Owner: neil.johnson71
Aug 2, 2013
#2 bahamasf...@gmail.com
Exciting! I'll give it a go...
Aug 16, 2013
#3 bahamasf...@gmail.com
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
#4 bahamasf...@gmail.com
Looks like it's a local on the stack, no?

Steve
Aug 16, 2013
#5 bahamasf...@gmail.com
Strangely, I get the same thing with printf. My compiler is really
broken, I guess. Disregard that one.

Steve
Aug 16, 2013
Project Member #6 neil.johnson71
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
Project Member #7 neil.johnson71
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
#8 bahamasf...@gmail.com
k, that's fine, thanks. I guess I can just wrap the include statement
itself in extern C.
Aug 16, 2013
Project Member #9 neil.johnson71
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
#10 bahamasf...@gmail.com
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
Project Member #11 neil.johnson71
If you're printing out real-world data try the new `!` flag for your `f` conversions.
Oct 23, 2013
Project Member #12 neil.johnson71
Support for most floating point formatting now implemented.
Status: Fixed

Powered by Google Project Hosting