[TUHS] printf (was: python)

Alejandro Colomar alx.manpages at gmail.com
Fri Aug 4 09:55:22 AEST 2023

Hi Dan,

On 2023-08-03 23:29, Dan Cross wrote:
> On Thu, Aug 3, 2023 at 2:05 PM Alejandro Colomar <alx.manpages at gmail.com> wrote:
>> On 2023-08-03 19:51, John Cowan wrote:
>>> On Thu, Aug 3, 2023 at 1:29 PM Alejandro Colomar <alx.manpages at gmail.com>
>>> wrote:
>>> But if speed is not a problem, I'd keep the good ol' syntax that
>>> everybody knows.  No need to make everybody learn a "cool" new print
>>>> function, that probably won't be as tunable as printf(3) is.
>>> By that argument, there would be no C, only Algol 68 and PL/I, or subsets
>>> of them.
>> I didn't claim that there's never a reason to invent new syntax.  My claim
>> was rather that in this case, there isn't.
>> -  printf(3) is more powerful than any other existing formatting function
>>    that I know of any language --I'm still curious of what's the equivalent
>>    of "%+'0#8.5f" in other formatting functions--.
> One issue is that this isn't standard C: the `'` verb for grouping by
> thousands is an SUSv2 extension. I just checked the latest C23 draft,
> and unless I missed it, it doesn't appear to have made it in.

Being in POSIX.1 it's portable to most (all?) current systems. ISO C
is a baseline for an implementation.  A quality implementation will
go beyond that standard (or will be rather useless).  POSIX.1 is more
of a useful thing.

But yeah, we can remove that "'" to get the idea.

> But things like that are fairly straight-forward in many other
> languages. For example, in Go, the format string is nearly identical,
> modulo the `'`:

Yup; I like go in that sense.


>> -  It is also reasonably fast (at least for such a highly-customizable
>>    formatting function), and I'd like to see any system beat that while
>>    keeping the customizability.
> At Google, a group of exceptionally talented engineers wrote a
> replacement in C++ for both type safety and because, bluntly, `printf`
> (actually `snprintf`) was too slow. I believe the overall mechanism
> made it into ABSL.

I think you mean absl::StrFormat().  It has printf(3)-like syntax, so
I can't say say much against it.  I don't know the details of how they
achieved the claimed 2x ~ 3x performance compared to snprintf(3).  I'm
curious to know if it's an inherent limitation of snprintf(3), or if
it's just that glibc is very unoptimized --which is true anyway, because
no-one has really maintained the printf(3) code in a long time--.

It's interesting, because then std::format() is not that miraculous
compared to snprintf(3).

>> -  It is type-safe, with the right tools.
> No it's not, and it really can't be. True, there are linters that can
> try to match up types _if_ the format string is a constant and all the
> arguments are known at e.g. compile time, but C permits one to
> construct the format string at run time (or just select between a
> bunch of variants); the language gives you no tools to enforce type
> safety in a meaningful way once you do that.

Isn't a variable format string a security vulnerability?  Where do you
need it?


More information about the TUHS mailing list