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=-10.9 required=5.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27580 invoked from network); 15 Dec 2021 21:40:33 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 15 Dec 2021 21:40:33 -0000 Received: (qmail 32701 invoked by uid 550); 15 Dec 2021 21:40:26 -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 32669 invoked from network); 15 Dec 2021 21:40:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yOrFApUPtC5R7wu5RCs2+uud5K7Og0J8AtsXzV+Pynw=; b=O1P2iYOV4l74P+bt3eHCG2br1PguqaYxC9nx4bpyFxr9bF7TOu0Y+fx+VhElkeLnlB pBkLeHYB6UT16cZVGQujIN/kSnYO9RTEo+kLrxk6scVjAz8pve/2gcpnrNNQQf33xhYJ NP9WBCpJEZTcQA3+JZ8dVjh0xaiQWVX/p9502YDFebd2pE8E/P89p5P7fzbjG1tvJMb/ XQmf8BVanNBYjgytshXOtqcg/rCYwSPXHVqPUg75D3sdj2QFed9kxJJgBBvjN70D2sSM llV+FDoeVsEHq4Se5/zl1czzlSKOHPGMxUpqJsMmecbb+M5fhz+aGfHgTrqWhr7fuBrG swUg== 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:cc; bh=yOrFApUPtC5R7wu5RCs2+uud5K7Og0J8AtsXzV+Pynw=; b=Q1TDlKnRoxhorcgxmAsTw7BDYqBVXrikbpYQcb8/pswnRDQKKHgxOjkjcmLh6D8oMz yj4boUNbKNydZ4pY6Jpm6bkbKTc5SDvujY4Ixy+RRfPL5E3ngegm2GRUq64fMFh3W+sD LtxUqHiY7VusvZmRz9nhZbJ/ENjImO7Qjd9/48o67v02KVlz1Rq7eBiwFJQl43zZ+FRg skIXt+Sfot02d4BbjzNHOTWDcKepcr7b21Ie8wYDCev8VoPrd5MxJ35Omqf5zM+eKge7 +nDDuHdxOJ5GbMPDDvXQXPo20xSYJWHPOIGqLH2lq/myRSA5Tpow4ggJvfINt24qPcE2 P8wQ== X-Gm-Message-State: AOAM53086/3aFnNkdxldn9JLTEKn7owqHDPKcN5/m1y3ykFrgiFbw4yf ob/DvNytHIctaaIn257zzwTn9PlbO7NvOMG/Dibxo9/6ZaI= X-Google-Smtp-Source: ABdhPJwtr30n8bbUqXAdHFpHu2SGFXxGk7GFCmJ8auX3IdmymxPpOus+wn/1R1DV2z/yRW9KjMOdXKPBUq5qCKJ8Org= X-Received: by 2002:a05:6512:230e:: with SMTP id o14mr12343516lfu.490.1639604413992; Wed, 15 Dec 2021 13:40:13 -0800 (PST) MIME-Version: 1.0 References: <20211214160327.GA1494342@port70.net> <20211215190914.233d3021.quinq@fifth.space> <20211215212126.GK7074@brightrain.aerifal.cx> In-Reply-To: <20211215212126.GK7074@brightrain.aerifal.cx> From: enh Date: Wed, 15 Dec 2021 13:40:02 -0800 Message-ID: To: musl@lists.openwall.com Cc: Andrew Snyder , Quentin Rameau Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] print does not support variable width plus padding On Wed, Dec 15, 2021 at 1:21 PM Rich Felker wrote: > > On Wed, Dec 15, 2021 at 01:37:43PM -0500, Andrew Snyder wrote: > > That is probably true but I think on accident trying to replicate my > > original issue which was using the native function > > With the program: > > #include > int main(int argc, char **argv) > { > printf("%0*i\n", 2, argc); > } > > (written using argc so it can't be collapsed to a constant string at > compile time) I get output of "01\n" as expected. If you think there's > a bug in musl for this or related functionality, can you provide a > minimal C test case? > > > On Wed, Dec 15, 2021 at 1:09 PM Quentin Rameau wrote: > > > > > Hi Andrew, > > > > > > > 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 > > > > > > This looks like you found a bug in Busybox printf implementation. > > FWIW I suspect the problem is that Busybox is not recognizing the 0 > character as a flag (which it is, in the printf grammar) and thinks > it's the leading character of a width, making the * specifier for > width invalid (since a width was already seen). yeah, since i was curious whether toybox had an issue too, i tested this (with bionic and glibc, but _not_ musl) and saw that coreutils and toybox both produce the correct output, but busybox fails with "invalid format" for glibc too. > Rich