[Devel] Feature request: error/debug message extension.

David Robillard d at drobilla.net
Sun Jan 15 15:57:18 PST 2012


On Sun, 2012-01-15 at 14:45 -0600, Gabriel M. Beddingfield wrote:
> On 01/15/2012 01:58 PM, David Robillard wrote:
> >> So we want to put *THAT* complexity on the host??
> >
> > If we must choose, yes!  Obviously.  I don't see why the heck you think
> > it's better to have it in the plugins...
> 
> Requiring hosts to do simple substitutions is fine with me.
> 
>  From the very start, I've been fine with something like this:
> 
>      format_string(s, BUFSIZE, "number = ?", (double)3);

Sure, simple formats, though:

* That syntax would not be possible in C because varargs are not type
safe (using something other than the standard C syntax for no reason is
silly anyway).

* A host-provided API wouldn't need a buffer and BUFSIZE (which is a
good thing) because it is a print function, not a format_string function

> ...and if you want more control over the formatting then you need to 
> bring your own.  This sort of thing is very easy to implement RT-safe.
> 
> I'm *not* fine with requiring hosts to support something like this:
> 
>      snprintf(s, BUFSIZE, "number = \\%-08.3g%%", (double)3);
> 
> ...UNLESS there is an RT-safe implementation of snprintf() available 
> somewhere.  (I'm even OK if the implementation actually ignores 
> everything except the type that's given.)

Not that I know of.  I have floating point print routines in svn serd,
but no printf.  It should be possible to even do one that streams (e.g.
to a ringbuffer) and requires no buffer size assumption at all, if you
want to get fancy.

So, restricted format strings, okay, but... is being able to print in
the audio thread worth all this?  What is a sensible non-debugging
example of wanting to do so?  Given the amount of PITA and how
ridiculously complicated this consideration is making a glorified print
function, I (and presumably anyone else who would have to implement it)
could use a compelling example or two... personally I doubt I'd even
implement the audio thread version otherwise.

-dr





More information about the Devel mailing list