public inbox for
 help / color / mirror / Atom feed
From: Jon Turney <>
To: "" <>
Subject: Re: bug with printf positional arguments?
Date: Mon, 3 Jul 2023 15:49:05 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 03/07/2023 12:14, Corinna Vinschen wrote:
> On Jun 28 14:28, Jon Turney wrote:
>> The following trivial program (extracted from a glib testcase)
>>> #include <stdio.h>
>>> int main()
>>> {
>>>    printf ("%1$*2$.*3$s", "abc", 5, 2);
>>> }
>> does not produce the expected output of "   ab", on 64-bit Cygwin.
>>  From a bit of staring at and stepping through get_args() in
>> libc/stdio/vfprintf.c, it looks like the problem is (something like) we
>> don't have the knowledge that the first positional variadic argument should
>> be treated as a pointer, at the point that we store it's value, so it gets
>> treated as an integer (the default), which is going to lead to truncation on
>> LP64 platforms.
>> A straightforward way to fix this eludes me.
> Can you point out where in the code this problem occurs, so maybe
> we can discuss the necessary code changes in this thread?

Sure, I'll try:

Let's suppose you're executing the STC above. This is what I think 

We end up in _vprintf_r.

We hit line 1072, which digests the '1', and on the following '$', knows 
to interpret this as a positional argument and stores it.

The subsequent '*' is processed at line 967 as introducing the width, 
where we chomp the '2', which again the following '$' indicates should 
be treated as a positional arg.

We hit GET_ARG for the first time, to retrieve the width, which invokes 
get_arg() to do the work (as we haven't yet stored the requested arg in 

get_arg() digests the format string (again) using a state machine (to 
populate args[] with the positional parameters)

The state machine moves through START (action NUMBER) -> WDIG (action 

Stopping here looks like maybe an error in the state machine design?

The loop starting at line 2310 iterates over the seen args, fetching 
their values. Because we haven't processed the 's' at the end in the 
GETARG state, we retrieve the first argument using the default case, as 
an integer (32 bits, truncating the 64-bit pointer value) (it looks like 
we're maybe also lucking out on handling the width properly, as we're 
never hitting the PWPOS state to record that it should be treated as an 

  reply	other threads:[~2023-07-03 14:49 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-28 13:28 Jon Turney
2023-07-03 11:14 ` Corinna Vinschen
2023-07-03 14:49   ` Jon Turney [this message]
2023-07-26 13:26     ` Corinna Vinschen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).