Hi Doug,
Doug McIlroy wrote on Tue, Dec 31, 2019 at 10:39:53AM -0500:
> It looks like Ralph has turned up a really strange bug in pic
> that suppresses pic's usual diagnosis of a bare % in a format.
>
> The example can be boiled down to
> sprintf("%g% %",1)
> which produces
> 1% %
> without complaint.
If can be boiled down even more.
sprintf("% %")
produced
% %
without complaint before my recently committed fix for the bug you
reported and
%
after the fix i committed for that bug.
The reason is that pic.ypp parses "% %" as follows:
'%': conversion sequence introducer
' ': flag: leave a blank before positive numbers
'%': conversion type: print percent character
So it treats "% %" as a conversion specification, passing it on to
the stdio snprintf(3) function. According to the C standard, the
result is undefined, but apparently, both glibc and OpenBSD libc
just print "% %". With Larry's tweak that i committed with my
bugfix, "% %" is treated exactly like "%%". That is allowed
because the C standard explicitly lets the behaviour of "% %"
undefined.
> If you omit either the 2nd or 3rd % though,
> pic announces "bad sprintf format".
Yes.
sprintf("%")
prints
%
and complains
bad sprintf format
Colin is working on a cleanup of this function right now IIRC.
Maybe he feels like moving the "%%" check *before* flag/width/precision
parsing. That would make "% %" error out. I'd welcome that.
It's hard to call that a bugfix, though. It's merely making
undefined behaviour fail rather than silently produce garbage.
Both are allowed unless otherwise documented.
But i do agree failing on invalid input is better than silently
producing garbage.
Yours,
Ingo
