printf() format extensions - looking for beta testers... 
Author Message
 printf() format extensions - looking for beta testers...

I have submitted a cover sheet to the C9X people for a new feature of printf,
which would provide user-defined format specifiers, and similar "features".

I have the beginnings of a real implementation to play with, and I am looking
for beta testers.

The basic idea of the proposed feature is that users would be able to install
new formats; for instance, the user would
do something like
        int bangcvt(va_list *ap, char *s, int len, fmtspec *f) {
                strncpy(s, strerror(errno), len);
                s[len - 1] = '\0';
                return strlen(s);
        }

        main() {
                format('!', bangcvt);

                /* do something which can generate an error */
                fprintf(stderr, "%s: %!\n", "open failed");
        }
...

(This example may not be correct, but is expected to give the idea of
intended usage.)

I would appreciate comments, suggestions, or volunteers.  I hope to have
a tested and portable implementation available "real soon now".

(Obviously, before any adoption occurs, it will be done with functions
not named printf/fprintf/etc.)

-s
--

C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
{*filter*} the communications decency act.  Goddamned government.  [literally.]
The *other* C FAQ - http://www.*-*-*.com/ ~seebs/c/c-iaq.html



Sun, 27 Sep 1998 03:00:00 GMT  
 printf() format extensions - looking for beta testers...
 >
 >
 > The basic idea of the proposed feature is that users would be able to install
 > new formats; for instance, the user would
 > do something like
 >         int bangcvt(va_list *ap, char *s, int len, fmtspec *f) {
 >                 strncpy(s, strerror(errno), len);
 >                 s[len - 1] = '\0';
 >                 return strlen(s);
 >         }
 >
 >         main() {
 >                 format('!', bangcvt);
 >
 >                 /* do something which can generate an error */
 >                 fprintf(stderr, "%s: %!\n", "open failed");
 >         }

Given the above, how about calls like (well, not a pretty one, but you get the
idea...):

        fprintf(stderr, "%-*.2!", something);

Later,
 AriL
--
All my opinions are mine and mine alone.



Tue, 29 Sep 1998 03:00:00 GMT  
 printf() format extensions - looking for beta testers...


Quote:

> >         int bangcvt(va_list *ap, char *s, int len, fmtspec *f) {
> >                 strncpy(s, strerror(errno), len);
> >                 s[len - 1] = '\0';
> >                 return strlen(s);
> >         }
>Given the above, how about calls like (well, not a pretty one, but you get the
>idea...):
>    fprintf(stderr, "%-*.2!", something);

This would call
        bangcvt(&ap, buf, len, { '!', something, 2, FMT_LEFT });
and leave the interpretation of the width and precision up to bangcvt.
flags are or'ed together.

It might not work correctly; I think my sample implementation may have a bug
in handling flags.  The principle is as given, though.

-s



Tue, 29 Sep 1998 03:00:00 GMT  
 printf() format extensions - looking for beta testers...

Quote:

>            format('!', bangcvt);

>            /* do something which can generate an error */
>            fprintf(stderr, "%s: %!\n", "open failed");
[...]
> (This example may not be correct, but is expected to give the idea of
> intended usage.)

A better example would have %! take one int argument:

                fprintf(stderr, "%s: %!\n", "open failed", errno);

That avoids problems with errno having been changed before the
formatting function gets a chance to look at it.  In particular, some
previous processing in fprintf may well have changed it.

[Good point. -mod]

Quote:
> (Obviously, before any adoption occurs, it will be done with functions
> not named printf/fprintf/etc.)

I'm not sure what you mean by this -- are you going to propose a whole
new family of I/O functions rather than an extension to the existing
functions?

[I mean I currently have a library of fmt(), ffmt(), sfmt(), snfmt(),
 vfmt(), ..., but that's a legality thing; the proposal would have that
 functionality named printf(), fprintf(), ..., but I can't send out
 reimplementations of library functions and expect it to work. -mod]
----
Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH  45150-2789  513-576-2070

I like Mom to be impressed when I fulfill the least of my obligations.
-- Calvin



Tue, 29 Sep 1998 03:00:00 GMT  
 printf() format extensions - looking for beta testers...


 >> >         int bangcvt(va_list *ap, char *s, int len, fmtspec *f) {
 >> >                 strncpy(s, strerror(errno), len);
 >> >                 s[len - 1] = '\0';
 >> >                 return strlen(s);
 >> >         }
 >
 >>Given the above, how about calls like (well, not a pretty one, but you get the
 >>idea...):
 >
 >>       fprintf(stderr, "%-*.2!", something);
 >
 >This would call
 >   bangcvt(&ap, buf, len, { '!', something, 2, FMT_LEFT });
 >and leave the interpretation of the width and precision up to bangcvt.
 >flags are or'ed together.
 >
 >It might not work correctly; I think my sample implementation may have a bug
 >in handling flags.  The principle is as given, though.
 >
  But there is a potential problem with doing this.  What if you use a
pre-compiled module that has extended printf(), say, using '%#' (unbeknownst
to you, the documentation may be a bit lax (happens enough)).  What happens
when you try to extend printf() using '%#'?  With possible different
semantics (different type, say)?

  -spc (Or does your printf() report a redefinition error?)



Wed, 30 Sep 1998 03:00:00 GMT  
 printf() format extensions - looking for beta testers...


Quote:
>  But there is a potential problem with doing this.  What if you use a
>pre-compiled module that has extended printf(), say, using '%#' (unbeknownst
>to you, the documentation may be a bit lax (happens enough)).  What happens
>when you try to extend printf() using '%#'?  With possible different
>semantics (different type, say)?

That's why mine is not like the plan 9 fmtinstall().  In my current design,
assuming that we have
        typedef int (*fmtconv)();
(args will vary as I struggle with the design), you install a format with
        fmtconv format(int c, fmtconv);

which installs a new format and returns the previous one.  There are special
magic fmtconvs called FMT_IGN (to make a character no longer a format
character), FMT_DFL (to reset to the default), and FMT_GET, which doesn't
install anything, but returns the current conversion func.

This has been described as overengineering, but is there for precisely
that reason.

%# would be a poor choice; the conversion func for %# is one which returns
a magic cookie to set the alternate format flag.  :)

But yeah, I've been thinking about it.

Quote:
>  -spc (Or does your printf() report a redefinition error?)

Nope.

I'm also considering the sfio magic of
        %(foo)
calling a conversion func attached to the string "foo".  This seems
frivolous for small apps, but if you look at a POSIX system, with
N+1 magic types like uid_t and gid_t, it might be useful.

I've been starting to get dazzled by the vast array of cool ideas
various previous implementations have come up with.  sfio has a base
flag, which could make the lives of thousands of first year students much
easier.

The problem is mostly coming up with a consistent way of parsing
things such that no currently standardized call to printf will change
behavior unless you've done something else (like call format()) which
is not standardized.

(Well, that would be trivial; but doing that and providing useful extensions
is more difficult.)

-s
--

C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
{*filter*} the communications decency act.  Goddamned government.  [literally.]
The *other* C FAQ - http://www.*-*-*.com/ ~seebs/c/c-iaq.html



Wed, 30 Sep 1998 03:00:00 GMT  
 printf() format extensions - looking for beta testers...

Quote:



>>  But there is a potential problem with doing this.  What if you use a
>>pre-compiled module that has extended printf(), say, using '%#' (unbeknownst
>>to you, the documentation may be a bit lax (happens enough)).  What happens
>>when you try to extend printf() using '%#'?  With possible different
>>semantics (different type, say)?

>That's why mine is not like the plan 9 fmtinstall().  In my current design,
>assuming that we have
>    typedef int (*fmtconv)();

  [ information about fmtconv() deleted ]

Quote:
>This has been described as overengineering, but is there for precisely
>that reason.

  To me it sounds horribly complicated and overengineered.  Simplify it 8-)

Quote:
>%# would be a poor choice; the conversion func for %# is one which returns
>a magic cookie to set the alternate format flag.  :)

  Oh.  Ah.  Well.  What IS available?

Quote:
>>  -spc (Or does your printf() report a redefinition error?)

>Nope.

>I'm also considering the sfio magic of
>    %(foo)
>calling a conversion func attached to the string "foo".  This seems
>frivolous for small apps, but if you look at a POSIX system, with
>N+1 magic types like uid_t and gid_t, it might be useful.

>The problem is mostly coming up with a consistent way of parsing
>things such that no currently standardized call to printf will change
>behavior unless you've done something else (like call format()) which
>is not standardized.

  Well, why not change the approach?  The current printf() will accept a
line such as:

                printf("%*s",someint,somestring);

  To allow variable widths to be specified.  Why not extend that and pass in
the function pointers?  Something like:



the type using a single letter specification:

                c       - char
                s       - short
                i       - int
                l       - long
                f       - float
                d       - double

  With the following modifiers:

                p       - pointer (if alone, void *)
                u       - unsigned

  Less chance of clashes, and more flexible I feel.

  -spc (Remember the KISS principle ... )



Thu, 01 Oct 1998 03:00:00 GMT  
 printf() format extensions - looking for beta testers...

Quote:

> >                 format('!', bangcvt);

> >                 /* do something which can generate an error */
> >                 fprintf(stderr, "%s: %!\n", "open failed");
> >         }
>Given the above, how about calls like (well, not a pretty one, but you get the
>idea...):
>    fprintf(stderr, "%-*.2!", something);

Yes, it seems that the format call back function (bangcvt) should take
a number of flags (leading 0/- found, precision, maximum width) and
a generic way to make the user defined format specifier output characters,
as it can be called from functions like "snprintf", which limit the output.
Passing a buffer to but the output in doesn't strike me as sufficient;
if "bangcvt" can have unlimited output, it must be possible for the
mechanism to cater for that.

And, of course, you want a input conversion as well :-)

So instead of:

Quote:
> >         int bangcvt(va_list *ap, char *s, int len, fmtspec *f) {

You'd get something more like:

    bangcvt (va_list *ap, int flags, int width, int precision,
        char fmt, int (*putit)(char c, void *output), void *output)

(Where you call "putit" for each character of output with *output
as magic for the call back)

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.



Thu, 01 Oct 1998 03:00:00 GMT  
 printf() format extensions - looking for beta testers...
Is it necessary to carry historical baggage by extending printf()?  It
might be preferable to have a new function with new syntax so you don't
need to worry about backward compatibility.

Stephen



Thu, 01 Oct 1998 03:00:00 GMT  
 printf() format extensions - looking for beta testers...


Quote:
>Yes, it seems that the format call back function (bangcvt) should take
>a number of flags (leading 0/- found, precision, maximum width) and
>a generic way to make the user defined format specifier output characters,
>as it can be called from functions like "snprintf", which limit the output.
>Passing a buffer to but the output in doesn't strike me as sufficient;
>if "bangcvt" can have unlimited output, it must be possible for the
>mechanism to cater for that.

But, of course, the current language only guarantees up to 509 characters.

It does get the flags; a fmtspec is a struct containing those and other
info.

Quote:
>And, of course, you want a input conversion as well :-)

Still working on that.

Quote:
>So instead of:
>You'd get something more like:
>    bangcvt (va_list *ap, int flags, int width, int precision,
>    char fmt, int (*putit)(char c, void *output), void *output)
>(Where you call "putit" for each character of output with *output
>as magic for the call back)

The problem is that function calls tend to be expensive.  The flags,
width, and precision are already in the fmtspec *.

-s
--

C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
{*filter*} the communications decency act.  Goddamned government.  [literally.]
The *other* C FAQ - http://www.*-*-*.com/ ~seebs/c/c-iaq.html



Thu, 01 Oct 1998 03:00:00 GMT  
 printf() format extensions - looking for beta testers...


Quote:
>>%# would be a poor choice; the conversion func for %# is one which returns
>>a magic cookie to set the alternate format flag.  :)
>  Oh.  Ah.  Well.  What IS available?

Whatever you want; it's just that if you change %#, you change the behavior
of existing legal programs.

Quote:
>  Well, why not change the approach?  The current printf() will accept a
>line such as:
>            printf("%*s",someint,somestring);
>  To allow variable widths to be specified.  Why not extend that and pass in
>the function pointers?  Something like:


>the type using a single letter specification:
>            c       - char
>            s       - short
>            i       - int
>            l       - long
>            f       - float
>            d       - double
>  With the following modifiers:
>            p       - pointer (if alone, void *)
>            u       - unsigned
>  Less chance of clashes, and more flexible I feel.

Well, that would break existing code, of course; you can actually
do something similar;
        int funcconv(va_list *ap, char *into, int len, fmtspec *fs) {
                fmtconv fc;

                fc = va_arg(*ap, fmtconv);
                return fc(ap, into, len, fs);
        }

And just bind this to whatever character you want.  (In my sample
implementation, it's %<.)

-s
--

C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
{*filter*} the communications decency act.  Goddamned government.  [literally.]
The *other* C FAQ - http://www.*-*-*.com/ ~seebs/c/c-iaq.html



Thu, 01 Oct 1998 03:00:00 GMT  
 printf() format extensions - looking for beta testers...

Quote:

>Is it necessary to carry historical baggage by extending printf()?  It
>might be preferable to have a new function with new syntax so you don't
>need to worry about backward compatibility.

Not necessary; I just think it's desireable, because printf already does
almost exactly what I want it to.  I just want to extend it.  I like
the idea of being able to use user-defined types.  (I dislike c++'s
iostreams, because precision should be a function of a given print, not
a stream; it is suboptimal to have to jump through hoops to print a
number with precision of N without having to save and restore things.)

-s
--

C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
{*filter*} the communications decency act.  Goddamned government.  [literally.]
The *other* C FAQ - http://www.*-*-*.com/ ~seebs/c/c-iaq.html



Thu, 01 Oct 1998 03:00:00 GMT  
 printf() format extensions - looking for beta testers...


[snip most]

:  Well, why not change the approach?  The current printf() will accept a
:line such as:
:
:               printf("%*s",someint,somestring);
:
:  To allow variable widths to be specified.  Why not extend that and pass in
:the function pointers?  Something like:
:

:

:the type using a single letter specification:
:
:               c       - char
:               s       - short
:               i       - int
:               l       - long
:               f       - float
:               d       - double
:
:  With the following modifiers:
:
:               p       - pointer (if alone, void *)
:               u       - unsigned
:      
:  Less chance of clashes, and more flexible I feel.




changing your modifiers to be consistent with "normal" ones; e.g.
"h" for short, "f" for double (note that float cannot be passed
here), etc.


a trigraph assigned to it, there are other problems with this...)

Cheers,
Stan.
--



Thu, 01 Oct 1998 03:00:00 GMT  
 printf() format extensions - looking for beta testers...


 >>>%# would be a poor choice; the conversion func for %# is one which returns
 >>>a magic cookie to set the alternate format flag.  :)
 >
 >>  Oh.  Ah.  Well.  What IS available?
 >
 >Whatever you want; it's just that if you change %#, you change the behavior
 >of existing legal programs.
 >
  Existing legal programs using your printf()?  

  I checked, and %#X is a legal (ANSI C) specification, wouldn't you know
8-)

 >>  Well, why not change the approach?

 [ much snipped ]

 >>  Less chance of clashes, and more flexible I feel.
 >
 >Well, that would break existing code,

  Again, existing code you wrote?  Gee, just like make requiring tabs (and
only tabs).  Can't fix it, because too many make files would "break" (sorry,
my anti-Unix bias is showing 8-)

 >of course; you can actually
 >do something similar;
 >   int funcconv(va_list *ap, char *into, int len, fmtspec *fs) {
 >           fmtconv fc;
 >
 >           fc = va_arg(*ap, fmtconv);
 >           return fc(ap, into, len, fs);
 >   }
 >
 >And just bind this to whatever character you want.  (In my sample
 >implementation, it's %<.)
 >
  But you still have the problem of overloading (what if I wanted to use %<
for something?).

  -spc (Hmmm ... I think we're straying here ... )



Sun, 04 Oct 1998 03:00:00 GMT  
 printf() format extensions - looking for beta testers...


Quote:


> >Whatever you want; it's just that if you change %#, you change the behavior
> >of existing legal programs.
>  Existing legal programs using your printf()?  

No... I mean that, if this extension or change were adopted, the goal is that
all currently defined programs continue to be defined to do the same thing,
and the changes will affect only code using new features.

Given that, though, if (using this extension) you were to change the behavior
of the # character in a printf format, previously written code would change in
behavior.  This is a feature, sort of, but is one to be wary of.

Quote:
>  Again, existing code you wrote?  Gee, just like make requiring tabs (and
>only tabs).  Can't fix it, because too many make files would "break" (sorry,
>my anti-Unix bias is showing 8-)

I'm not sure how a makefile using tabs would break on a make allowing
tabs-or-spaces, but that's atopical; feel free to email me with an example.

No, I mean existing code *anyone* wrote; the goal is to change the behavior of
no existing program, and make it possible for people to use the new features
as consistently as possible.

Quote:
>  But you still have the problem of overloading (what if I wanted to use %<
>for something?).

Then you'd change it.  My current design allows you to make %d always print a
1.  You are not required to use the standard set of flags.  (This is a quality
of programmer issue.)  The idea would be to offer some new format flags,
and then also provide a generic way to add new ones, or replace old ones.

I'm hoping to get this or a similar proposal added, because it would make my
lifie immensely easier.  I'm still looking at similar proposals.  I have
decided that I'm probably going to have to choose a different way to pass data
around, though.

-s
--

C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
Unsolicited email is not welcome, and will be billed for at consulting rates.
The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html



Sun, 04 Oct 1998 03:00:00 GMT  
 
 [ 20 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Looking for Beta Testers

2. Looking for Beta testers for distributed compilation software.

3. TabStripPanel Control Beta Released - Beta Testers Wanted!

4. Beta Testers needed

5. Beta testers wanted + HashtableList

6. Beta Testers needed

7. BETA TESTERS WANTED!!!

8. BETA TESTERS NEEDED!!!

9. C/C++ Exam Beta Testers Requested

10. Pre-release C Beta Testers

11. Free Technical Training - Be a Beta Tester!

12. I'm a beta tester

 

 
Powered by phpBB® Forum Software