[TUHS] Re: printf (was: python)

[Dan Cross <crossd@gmail.com>]

On Thu, Aug 3, 2023 at 7:55 PM Alejandro Colomar <alx.manpages@gmail.com> wrote:
> 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.

I don't know that that's true, but I can see how one could get into a
"no true Scotsman" fallacy pretty quickly arguing over it.

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

I don't recall the details now, but I seem to remember that much of it
was moving the burden of parsing the formatting directives to compile
time (though I may be misremembering).

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

It _can_ be a security vulnerability, but it doesn't necessarily
_need_ to be. If one is careful in how one constructs it, such things
can be very safe indeed.

As to where one needs it, there are examples like `vsyslog()`, but
that's almost besides the point, which is that given that you _can_ do
things like that, the language can't really save you by type-checking
the arguments to printf; and once varargs are in the mix? Forget about
it.

        - Dan C.