🚀 go-pugleaf

In article <4koecq$8up@solutions.solon.com> seebs@solon.com writes:
>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)();

  [ information about fmtconv() deleted ]

>This has been described as overengineering, but is there for precisely
>that reason.
>
  To me it sounds horribly complicated and overengineered.  Simplify it 8-)

>%# 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?

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

		printf("%p@",myfunctptr,myptrtype);

  Where '@' specifies a format function, and the letter before it declares
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 ... )