Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This is that huge sprintf thing I've been working on all week.
One possible problem: Sun's compiler seems to continually complain about our varargs accesses. I don't know if the current approach will work correctly, but I suspect it will. From one of the announcement e-mails: *** First of all, it completes the feature set of the Parrot_sprintf family, including width and precision for ints and strings. It also makes handling of strings and floats safe. Further, it changes the old %P format (PMC) to a new P size--%Ps, %Pd, %Pf, etc. It fixes the problem with HUGEINTVAL by auto-detecting it at compile time. (If you compile Parrot on a machine that supports long long, %Hd will format one; same with long double and %Hg.) It adds PIO_printf, PIO_eprintf (error printf) and PIO_fprintf. The first two default to stdio if there's no interpreter available. It modifies the Parrot_warn family and PANIC to use PIO_eprintf. It modifies every file that has access to PIO (in other words, anything that includes parrot.h) to use PIO_printf and PIO_eprintf. It slightly modifies conversions between STRINGs and FLOATVALs, using %g instead of %f. *** And the other one: *** Inspiration struck me as I was working on bug fixes for Parrot_sprintf's patch yesterday. One of my long-term goals with Parrot_sprintf was to use it as the engine for a Parrot bytecode-level sprintf opcode, but I didn't think that would be possible without duplicating the code in two different files with different versions of the same macros wrapping accesses to the arglist. Obviously, this is a Bad Thing, so I just let my mind crunch on it a while. Until today, when I realized the solution that had been staring me in the face all along. The answer was vtables. A specialized vtable wrapping argument accesses would mean one version of the formatting code, but two different behaviors! Excited, I set to rewriting Parrot_sprintf--*again*--to use this idea. Along the way, %S went the way of %P (you should now use %Ss to insert a STRING*, but %S will still work), two new opcodes got added, and I managed to remove several restrictions on strings that I had imposed on myself by using C strings internally instead of Parrot ones. The result (I hope) is better, faster, and stronger than the original. When misc.c reached around a thousand lines, I decided it was becoming unmanageable, so I split misc.c into three files. Misc.c contains the public "wrapper" functions around the core formatter, spf_render.c contains the formatter and some utility functions, and spf_vtable.c contains the two vtables used to make Parrot_sprintf work. *** Includes an expanded test suite in t/src/sprintf.t and another test in t/op/string.t. All tests pass on Cygwin and Win32, 'cept t/src on Win32, which didn't work in the first place. git-svn-id: https://svn.parrot.org/parrot/trunk@2372 d31e2699-5ff4-0310-a27c-f18f2fbe73fe
- Loading branch information
brentdax
committed
Oct 11, 2002
1 parent
02c63c7
commit 53b5369
Showing
51 changed files
with
3,327 additions
and
1,725 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -585,6 +585,8 @@ rx.c | |
rx.ops | ||
rxstacks.c | ||
smallobject.c | ||
spf_render.c | ||
spf_vtable.c | ||
stacks.c | ||
string.c | ||
sub.c | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.