Re: [PATCH v3] Make fprintf() function to multithread-safe

["Ryan S. Arnold" <ryan dot arnold at gmail dot com>]

On Mon, Jul 23, 2012 at 8:39 PM, Rich Felker <dalias@aerifal.cx> wrote:
> The most likely _candidate_ usage case would be when the format
> specifier is registered from a constructor or explicit init function
> in a library that's loaded with dlopen rather than at program startup.
> But is it really reasonable design for libraries to be registering
> printf specifiers anyway?

Initialization from a library constructor is exactly how Libdfp
registers printf hooks for the ISO C DFP TR format specifiers
%H,%D,%DD.

Library registration of hooks is the exact reason that the relatively
recent changes to printf hooks were added.  If GLIBC doesn't want to
support ISO C Technical Report specification proposals (even when
ratified) for data-types directly (including printf format specifiers)
but those same specification proposals propose seamless handling of
the new data-types by printf then GLIBC has little choice.

It wouldn't be a big issue if the ratification and adoption timeline
wasn't so horrendously long.   I suspect that the ISO DFP TR, while
ratified, won't be added to the official standard until the next major
revision and it was 12 years between C99 and C11.  So it's been
recognized that it's not fair for GLIBC to stick it's head in the sand
and pretend like those data types don't exist.

> What I'd really prefer to see is for this entire functionality to be
> deprecated, and if it's really needed, replaced by an equivalent
> mechanism without global state in the form:
>
> printf("%Q", custom_format_object, my_data);
>
> where custom_format_object is either a pointer to a caller-filled
> structure of an opaque pointer obtained by a function to allocate a
> new printf custom formatting, and "%Q" is a random letter I made up to
> indicate to printf that it should expect such a pointer followed by a
> pointer to the actual data.

> This would be entirely stateless, would not run into a limit on the
> number of custom formats, and would not have libraries stepping on
> each other if/when they try to use it.

The printf API is governed by the ISO C specification (which changes
slowly and by committee).  It's a terrible beast best left in the
labyrinth and I'd prefer if as little was done to it as possible.
This might work as a different API entirely but I'd like to see an API
which provides compile-time type determination rather than runtime...
but this may not be possible.

> With that said, I question the value of the whole thing. It seems a
> lot more reasonable to just have your custom data types provide a
> convert-to-string method that can then be passed as the argument with
> a %s specifier without relying on non-portable GNU printf extensions.

As hard as it is to swallow, this is contrary to the provisions in the
ISO C specification technical reports which provide seamless printf
support for new data-types.

I'm a bit sensitive to this topic since it took years to get GLIBC to
provide full featured printf-hooks in the first place.

Ryan S. Arnold
Libdfp maintainer