[TUHS] printf (was: python)

[Alejandro Colomar <alx.manpages@gmail.com>]

Hi Dan,

On 2023-08-03 23:29, Dan Cross wrote:
> On Thu, Aug 3, 2023 at 2:05 PM Alejandro Colomar <alx.manpages@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@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?

Thanks,
Alex