Re: fmtcheck() query

[Rin Okuyama <rokuyama%rk.phys.keio.ac.jp@localhost>]

On 2017/12/07 22:55, Robert Elz wrote:> I made a change to:
> 	src/tests/lib/libc/gen: t_fmtcheck.c
>
>    Log Message:
>    Correct a couple of broken test cases:
> 	"%d"  does not take the same args as "%d %s"
> 	"%%"  does not take the same args as "%llx"
>    How did these ever survive any kind of even basic sanity check?
>
> which corrects a failing test case after the recent fmtcheck() updates.
>
> But in hindsight I am wondering if this is really correct (though it
> matches what the man page says the function should do).
>
> The broken tests were cases where the "suspect" format string consumes
> less args than the standard one, but where the args consumed are all of
> the correct types (ie: it will leave some args unused.)
>
> This is a case which could possible be permitted, it should do no harm
> to use a user supplies (eg: message catalog) format string which doesn't
> use all the args, as long as those it does use are of suitable types.
>
> Since, until the recent changes to fmtcheck() these tests used to pass,
> it seems that that was what out old fmtcheck() used to permit, and the
> updated one does not.
>
> Which do we want?

Thank you for fixing the failing cases. I had overlooked them.

I consider the current behavior is better than before. As you pointed
out, format strings consuming few arguments do no harm *technically*,
as long as they are of correct types. However, information is partially
lost as a result. I believe providing full information in English is
much better than printing insufficient one in users' native tongues.

Also, I'm writing a program which sanitizes message catalogs for nvi
statically. If we choose the previous behavior, I can no longer use
fmtcheck for this purpose.

Perhaps, you may suppose a case where some arguments are necessary for
English, but they are not for some languages. For example, something
like

    (n > 1) ? "files" : "file"

is meaningless in Japanese, which does not distinguish the singular and
plural. However, this kind of matter can not handled in the framework
anyway; how should we do when we do not want the 3rd, but need the 4th
arguments?

How do you, and others, think?

rin