IExec->RawDoFmt() is an exec call installed for minimal I/O. It doesn't handle floating point variables [neither does its more modern replacement, IUtility->SNPrintf()].
Applications that want to output floating point are likely to use the C runtime library, so they can use printf().
tonyw wrote: IExec->RawDoFmt() is an exec call installed for minimal I/O. It doesn't handle floating point variables [neither does its more modern replacement, IUtility->SNPrintf()].
In fact I noticed that using IUtility->SNPrintf()
Quote:
Applications that want to output floating point are likely to use the C runtime library, so they can use printf().
No my application wants to display frequencies in Hz with two fractional digits. Calculus is done using lib fftw3 which might (probably) use C runtime functions but my application is only trying to display this into a string gadget and don't use any C runtime functions until now.
OK, I'll ask the question a different way - why use IUtility->SNPrintf() at all, if it doesn't do what you want (floating point) ?
By "native" calls, I suppose you mean AOS-centric calls? Why restrict yourself to AOS-centric calls? Why not use the standard, built-in C library that's already there? No one is going to think less of you if you use built-in calls and external-library calls in the same module.
Maybe I'm missing the point, but I don't understand your reluctance to use the standard tools provided.
tonyw wrote: OK, I'll ask the question a different way - why use IUtility->SNPrintf() at all, if it doesn't do what you want (floating point) ?
I didn't know SNPrintf was not doing what I wanted until I noticed it...
Quote:
By "native" calls, I suppose you mean AOS-centric calls? Why restrict yourself to AOS-centric calls? Why not use the standard, built-in C library that's already there? No one is going to think less of you if you use built-in calls and external-library calls in the same module.
Maybe I'm missing the point, but I don't understand your reluctance to use the standard tools provided.
There was a time when mixing DOS I/O calls with C runtime I/O calls wasn't a good idea since then I try to not mix them as safety measure.
And its still a good idea, because dos.library and C runtime still carry their very own contexts.
There is some kind of warranty that mixing up these contexts will do no harm to the system, but as context information is very scarce (still), there is some danger that a coder might mess up one or the other context, on e.g. program termination, by accident (e.g. Exit() instead of exit() for an "emergency shutdown" and some other cases still not cleared).
Edit: Forgot something Portability in mind is always a nice idea, but for AmigaOS only programs its quite useless to keep "portability" by using C runtime libraries. A program wont get portable magically by using C runtime calls only.
It depends on the intentions of the developer, if a program is "portable" by design or not. So, please, dont push developers to portability where it makes few or absolutely no sense.
There was a time when mixing DOS I/O calls with C runtime I/O calls wasn't a good idea since then I try to not mix them as safety measure.
Indeed, this is not a good idea to mix them for standard I/O (unless you Flush() DOS streams and fflush() C streams between the two). However, if I got it right you just want to format a buffer, so here using snprintf() is not a problem at all since neither malloc() nor standard streams are involved. And if you are not in a shared library there is no issue with startup code. Maybe portability is not a good reason to use it, but code simplicity is, I would not extract by hand fractional part just to avoid using snprintf("%f")
Hehe, yes... but it would be even more simple to implement floating point output for SNPrintf(), so one doesnt have to hassle with the (possible) caveats of using a system call/C runtime call mix.
I never understood why they chose to call the "more modern" RawDoFmt-replacement exactly like the full-fledged C runtime call, but dont implement the full functionality (thats a reason to ask where it indeed IS more modern, besides the name).
It would have been more clever to keep RawDoFmt as THE absolute low-level-call it was all the time, and give the functionality developers would expect to the SNPrintf() call (even more as its located within utility.library and not within exec.library).
Or, if some basic ouput function detached from exec context is needed so badly, give it another name.
I never understood why they chose to call the "more modern" RawDoFmt-replacement exactly like the full-fledged C runtime call, but dont implement the full functionality (thats a reason to ask where it indeed IS more modern, besides the name).
It seems quite obvious SNPrintf (just like ASPrintf) was only added to fill the gap missing in the RawDoFmt family (since there already was Printf, FPrint, VPrintf etc...), not to be compatible with snprintf. Same goes for StrlCat, StrlCpy... If you need C runtime flavours in a shared library, better use newlib. BTW, the new FormatString32() of locale.library seems quite useless now since AFAIK no system function make use of it.
There is still the question, why on earth there is still NO system function with the ability to output formatted strings containing float numbers. Or simply convert float numbers into a string, which in turn is copied to a string buffer, which in turn could be used by the well-known output functions.
utility.library would be a perfect place for functions like this.
You mean newlib, dont you? Well, the duplicating of library code argument would be futile then, as there is much more trouble to cure, if a program uses clib2 AND dos.library buffered file I/O calls additionally. And no documentation about all this and how to use it correctly, if you need some low-level functionality.
I think the "mess" is of your own making. No one should be using clib2 these days, it is not thread-safe and is obsolete. There is no problem using newlib calls mixed with calls to utility.library, although it seems to me to be a duplication: I can do far more with an "sprintf()" in C than I can do using utility.library, and I can look it up in any C textbook.
I still don't see a problem, but I'll leave it at that, we're getting nowhere with this discussion.