🚀 go-pugleaf

Peter Seebach wrote:
 > 
 > 
 > 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.

In article <4klicn$ndl@solutions.solon.com>,
Ari Lukumies  <aril@cmt.lpr.mail.carel.fi> wrote:
>Peter Seebach wrote:
> >         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

In article <4kgljv$l2p@solutions.solon.com>, seebs@solutions.solon.com (Peter Seebach) writes:
> 		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]

> (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
larry.jones@sdrc.com
I like Mom to be impressed when I fulfill the least of my obligations.
-- Calvin

In article <4kll9l$o5h@solutions.solon.com> seebs@taniemarie.solon.com (Peter Seebach) writes:
 >In article <4klicn$ndl@solutions.solon.com>,
 >Ari Lukumies  <aril@cmt.lpr.mail.carel.fi> wrote:
 >>Peter Seebach wrote:
 >> >         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?)

In article <4kobun$8i2@solutions.solon.com>,
Sean 'Captain Napalm' Conner <spc@gate.net> wrote:
>  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.

>  -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
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach.
C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
FUCK the communications decency act.  Goddamned government.  [literally.]
The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html

Ari Lukumies <aril@cmt.lpr.mail.carel.fi> writes:

> >                 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:

> >         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.

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

In article <4kr78t$kao@solutions.solon.com>,
Casper H.S. Dik - Network Security Engineer <Casper.Dik@Holland.Sun.COM> wrote:
>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.

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

Still working on that.

>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
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach.
C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
FUCK the communications decency act.  Goddamned government.  [literally.]
The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html

In article <4kr7aj$kbs@solutions.solon.com>,
S. Lee <sl14@crux1.cit.cornell.edu> wrote:
>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
-- 
Peter Seebach - seebs@solon.com - Copyright 1996 Peter Seebach.
C/Unix wizard -- C/Unix questions? Send mail for help.  No, really!
FUCK the communications decency act.  Goddamned government.  [literally.]
The *other* C FAQ - http://www.solon.com/~seebs/c/c-iaq.html

In article <4kr78t$kao@solutions.solon.com>,
Casper H.S. Dik - Network Security Engineer <Casper.Dik@Holland.Sun.COM> wrote:
>Ari Lukumies <aril@cmt.lpr.mail.carel.fi> writes:
>> >                 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.

All of this (and more) has been done, already.  I posted the "prf" package
to "alt.sources" in December 1993.  An extract from the README is below.

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

True, but that is missing in "prf", too.  :-(

>So instead of:
>
>> >         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)

In "prf" there are two structs, one to describe the conversion specification
(from parsing the format string), and the other to describe the destination
of the output.  To call a function for every single character is just
one of the alternatives.  Others destinations are a simple FILE* or a limited
memory buffer.  The above now looks like:

    bangcvt (PrfDest* dp, PrfSpec* sp, va_list* ap)

The following is an extract of the README for the "prf" package:

|This is the first public release of the ``prf'' library, an extended
|and user programmable printf clone.
|
|For a description of function and interface see the manual page (prf.3x),
|e.g. with "nroff -man prf.3x | col | more -s".  A manual page output
|stripped down to plain ASCII can be found in "prf.3x.raw".
|
|In very short terms: what is this library good for?
|- After initializing the prf library with e.g. "stdprf();fltprf();extprf();",
|  you can call prf() instead of printf(), sprf() instead of sprintf,
|  and fprf() instead of fprintf(), and should get the same output.
|- You can use more/better conversions (e.g. prf("%b", 5) yields "101").
|- You can write new conversion functions and bind them to, say, "%z".
|- You can use other interface functions to have the output (format string
|  with embedded conversions) go into whatever destination you want it.
|
|The intent of the copyright notice in the sources and the file COPYRIGHT
|is to avoid legal problems and prevent others from claiming to be the author.
|No further restrictions are intended.
	[snip]
|At the time the prf library were written, I had no ANSI C available.
|Hence, it is all plain K&R C.  [snip]
|
|As far as possible and meaningful the prf library is consistent
|with ``printf'' as described in SVID and BSD 4.3 printf(1) manual page.
|As those descriptions are not at all complete, different behaviour
|of printf and prf in some details should be expected.
	[rest omitted]

The major drawback of the package seems to be that it is old K&R.
It definitely should be redone in ANSI-C.  There are also some
features still missing (e.g. flushing an arbitrary destination, or
installing format call back functions just by loading).

All in all, I have found "prf" inspiring and quite useful for years.
--
Heiner Marxen			heiner@drb.insel.de