Re: Fwd: Re: fmtcheck() query

[christos%astron.com@localhost (Christos Zoulas)]

In article <21339.1513042366%andromeda.noi.kre.to@localhost>,
Robert Elz  <kre%munnari.OZ.AU@localhost> wrote:
>    Date:        Mon, 11 Dec 2017 14:17:15 +0000 (UTC)
>    From:        uwe%stderr.spb.ru@localhost (Valery Ushakov)
>    Message-ID:  <p0m41b$qv5$1%blaine.gmane.org@localhost>
>
>
>  | I guess the reason behind that requirement must be the fact that it's
>  | not possible to skip arguments with va_arg().  So e.g. for "%3$s %1$d"
>  | you wouldn't know how to get to the third argument as there's no type
>  | info for the second: is it a 4-byte int, or 8-byte pointer, or 8-byte
>  | double, etc.
>
>There really needs to be a new format flag to specify that the conversion
>is not to actually be used (generates no output at all) but which can be used
>to specify the argument type, so one might write for the example you gave
>
>	"%3$s %1$d%2$!e"
>
>(where '!' is the new flag char) after which we know what type (what
>size really) the unused 2nd arg is, but it is never actually used.
>(The %2$!e part could be placed anywhere in the string with the same effect.)
>
>But we don't have that (yet anyway...)
>
>  | OTOH, we can't tell if the format misses some arguments intentionally.
>
>I don't think that's fmtcheck's job.   Its purpose is (or should be) to
>make sure the program does not mis-use the args (print some part of a
>floating value as if it were a pointer...) rather than that it is perfect.
>
>There are good reasons why args might want to be omitted sometimes, and
>I think that should really be supported (trailing args particularly.)

Yes, at least the new behavior made file(1) break and I am sure it is going
to break more 3rd party software that depend on this behavior. For example
file(1) uses fmtcheck to make sure that the formats in the description field
match the implicit type of the file entry line. Some description lines don't
use the values so they don't have format entries. Of course it was easy to
fix in this case by checking that the description contains a '%' and if it
does not, to skip the fmt_check() alltogether. Having said that, I agree
that the new behavior should be optional and since we are going to replace
fmt_check() with a new function that handles positional arguments we can
also add a flag to require exact matches or not.

christos