4 Aug
2023
4 Aug
'23
6:06 p.m.
On Thu, Aug 3, 2023 at 7:55 PM Alejandro Colomar <alx.manpages(a)gmail.com> wrote:
On 2023-08-03 23:29, Dan Cross wrote:
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.
On Thu, Aug 3, 2023 at 2:05 PM Alejandro Colomar
<alx.manpages(a)gmail.com> wrote:
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. On 2023-08-03 19:51, John Cowan wrote:
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. On Thu, Aug 3, 2023 at 1:29 PM Alejandro Colomar
<alx.manpages(a)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--. But yeah, we can remove that "'" to get
the idea.
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).
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. It's interesting, because then std::format() is
not that miraculous
compared to snprintf(3).
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.
- 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.