From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 1832 invoked from network); 14 Dec 2021 16:10:49 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 14 Dec 2021 16:10:49 -0000 Received: (qmail 9701 invoked by uid 550); 14 Dec 2021 16:10:47 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 9661 invoked from network); 14 Dec 2021 16:10:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=CSpHlJMndyWBd088uJ6Mn1yJcOUY88bPWIeBJUN7qcc=; b=a5TnhWvQ10e+KRwNBoknESfseChByOIy3/8W6E+OT8C1k5xT/czM8E4KnNe9Vq8ruB 0ii/SOy/MuVApskmR6+emOEW9/jYIIn8ThQARMwDYSyxrvj1SyOIjhVrM8wyHSb03oz5 l/VcAzgpzBlNqMLNJTdu3h/nnTNzFJOPrtYBJhjrYX7uOsHaHaB6y1hJbvafBE9KcxAQ BOHMzsLwuD/U7HbU7+W216gqixEC8KOOFtzpcHgDs2EoT3llEaQA/ERovmiXprmm0zyk 25gJg8Lmj+G1NWUhs2BpqdQ0D016tW3V5kmY6S0nrXJmIbneAA0lb+NC46eLxLyMlxIV fcqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=CSpHlJMndyWBd088uJ6Mn1yJcOUY88bPWIeBJUN7qcc=; b=GnL4GgqymDLcgsdouhDdFK/nOVbCpyBoBVPwOdES7FE7OWIFoWu/Ed1eyes1POqf5j QuX80oeuoJNt/OQPffRTV3Ez/dyKNwQK+2TqY42eTiC2Q122vSjcM0pLwHkLxLtulN3H aF661YJ47pSzt8kALW29C3NVCoIVclh7tFnBw/4LrIY7bmu4CGCorY/IPqtm+sfMXwpa nPcxn0atlwuYxViO9HVLCjxZ2DMXoMUqZsJYSofDfg8igSsa8jcU+Y9Trn7me9GfW1I9 x7iLQ/bHAIjYw4u1ntgu/UoiN+AzDAUno3pW1H0EanjLVHOlQi8Aq7LjWkHa0HlsaKko l2kg== X-Gm-Message-State: AOAM531T1dhv7vio+TQwTOAi5SpDqPW+Fq1coasRnAsHJIgp7TQRFx2X K5wPnQ14MoRAgfJlUUzyr/mASB6QPMTrWckzsiXiCrxNIlU= X-Google-Smtp-Source: ABdhPJwWA8RCAN2IATHfe78zcYVN8B7oxcLG8wVOyYCxnkWrKJBNq4NPoo6+q6wlGepGRtTnBV6L2iql3fI0227Hnu0= X-Received: by 2002:a05:6122:1788:: with SMTP id o8mr6944618vkf.8.1639498234836; Tue, 14 Dec 2021 08:10:34 -0800 (PST) MIME-Version: 1.0 References: <20211214160327.GA1494342@port70.net> In-Reply-To: From: Andrew Snyder Date: Tue, 14 Dec 2021 11:10:23 -0500 Message-ID: To: Andrew Snyder , musl@lists.openwall.com Content-Type: multipart/alternative; boundary="000000000000e5ba1a05d31d6dd4" Subject: Re: [musl] print does not support variable width plus padding --000000000000e5ba1a05d31d6dd4 Content-Type: text/plain; charset="UTF-8" Sorry accidentally sent before attaching this ~# docker run -it --rm alpine /bin/ash / # /lib/libc.musl-x86_64.so.1 musl libc (x86_64) Version 1.2.2 Dynamic Program Loader Usage: /lib/libc.musl-x86_64.so.1 [options] [--] pathname [args] / # printf %0*i 2 1 ash: %0*i: invalid format On Tue, Dec 14, 2021 at 11:09 AM Andrew Snyder wrote: > I get an error from printf i assume that underlying printf function is > returning error code. In my native implementation i get incorrect results > and really depends on the parameters i didn't dig into too deep to see what > the pattern was > > > On Tue, Dec 14, 2021 at 11:03 AM Szabolcs Nagy wrote: > >> * Andrew Snyder [2021-12-14 10:22:42 -0500]: >> > I would like to be cc'd on the replies >> > >> > Looks like a bug in the musl printf functionality >> > >> > When using variable width format string and specifying a padding musl >> fails >> > to format properly. >> > >> > I am using musl indirectly through an emscripten compile of a native >> > library. >> > >> > Consider the following repro steps using alpine docker image. Correct >> > results exist when using ubuntu image >> > >> > # Correct expected ' 1' >> > docker run -it --rm alpine printf %2i 1 >> > # Correct expected ' 1' >> > docker run -it --rm alpine printf %*i 2 1 >> > # Correct expected '01' >> > docker run -it --rm alpine printf %02i 1 >> > # errors, Expected '01' >> > docker run -it --rm alpine printf %0*i 2 1 >> >> i get the expected result on alpine >> >> $ printf %0*i 2 1 >> 01 >> >> what do you get? >> >> --000000000000e5ba1a05d31d6dd4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry accidentally=C2=A0sent before attaching this=C2= =A0

~# docker run -it --rm alpine /bin/ash
/ # /lib/= libc.musl-x86_64.so.1
musl libc (x86_64)
Version 1.2.2
Dynamic Pro= gram Loader
Usage: /lib/libc.musl-x86_64.so.1 [options] [--] pathname [a= rgs]
/ # printf %0*i 2 1
ash: %0*i: invalid format

On Tue, Dec 14,= 2021 at 11:09 AM Andrew Snyder <arsnyder16@gmail.com> wrote:
I get an error from printf i assume t= hat underlying printf function is returning error code.=C2=A0 In my native = implementation i get incorrect results and really depends on the parameters= i didn't dig into too deep to see what the pattern was=C2=A0

<= /div>

On Tue, Dec 14, 2021 at 11:03 AM Szabolcs Nagy <nsz@port70.net> wrote:
* Andrew Snyder <arsnyder16@gmail.com= > [2021-12-14 10:22:42 -0500]:
> I would like to be cc'd on the replies
>
> Looks like a bug in the musl printf functionality
>
> When using variable width format string and specifying a padding musl = fails
> to format properly.
>
> I am using musl indirectly through an emscripten compile of a native > library.
>
> Consider the following repro steps using alpine docker image. Correct<= br> > results exist when using ubuntu image
>
> # Correct expected=C2=A0 ' 1'
> docker run -it --rm alpine printf %2i 1
> # Correct expected=C2=A0 ' 1'
> docker run -it --rm alpine printf %*i 2 1
> # Correct expected=C2=A0 '01'
> docker run -it --rm alpine printf %02i 1
> # errors, Expected '01'
> docker run -it --rm alpine printf %0*i 2 1

i get the expected result on alpine

$ printf %0*i 2 1
01

what do you get?

--000000000000e5ba1a05d31d6dd4--