From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id F21C62B656 for ; Wed, 12 Jun 2024 21:22:28 +0200 (CEST) Received: (qmail 9520 invoked by uid 550); 12 Jun 2024 19:22:23 -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 9481 invoked from network); 12 Jun 2024 19:22:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1718220134; x=1718824934; darn=lists.openwall.com; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=WBy4QpAjwMPrv68lLcR/d19MIeDHBc72NgjhHUHtvU4=; b=0GL+pxHEvc7bwkZgkk8nORQJFNMgQMg/43ftCoki2djuV+VhPWj9wNfzUTA8/Qg2Qm vO74H+vwExlx6k8qtGLGkuDE7fzfhLk6LIPOhYpUDF9Kzp196hsRL4h9nc0cGrSCtlhl 59cgq18QzjNGxH1c2s4Db+xggODkz2bd42L9sPDCmuF/LRF1XenTZSs7BXXU7GGqC/Zi OGuL0k/QgBC8NVv9z/CjJ1kSjYqABEOY6bv4i75og7AQTulgoWOKiVfwihxHC4OauyDE VU+ln2DFsAqw9m0iHm6wcQP8o/WxArhlGPVOEPaedf/XwyipUVZFPKA7D9kZ/IiFgPFe EKFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718220134; x=1718824934; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WBy4QpAjwMPrv68lLcR/d19MIeDHBc72NgjhHUHtvU4=; b=n7I8IGh9oBNNQuFoZWp1yWFlkRMVayGXrBj+x39zmp+wkoBRV6HVxqtLUldOEvQ3ky FW7Btcq4S0dUdxUoo5DYuVcHVVZTGnmXNe26dtAvd3+VNFqwik1SOy1KxWrfWBTsvbNn iSztQ0FSax6i8oUkdJGFXq4BBFAk5WTlIG4GH0LXRhz8bg589gm87sLwqIX/XqXps5rr 8g0LWARUYXPHVzn7XYKH93tWwkTgSXm5prPBQ9PTV8TPRlrZkMHKqrCgR/zZvXrj/ENy 6e69JUuk/vLkBHSX6LuFJQk1OwbuSsSQIUEDb694ffgeDWYSKCieDw71Y2Hv8MRuErDc zaxg== X-Gm-Message-State: AOJu0YxoZxJD0SlEB1SWXddmJ1QCG7q4gtOGC8N5/zHTyL+JggkZTSGQ JSDdNvUmAtdupI6XuBjbAyXCiOAfN9XTWxfZZkoh35FNOJIC2bf5bcSvNowYIvDTaPDfbiDq5UH 8xNyMyOqiMZaRPAoiR5uN1QyW8PzugUL965BJ7vTG5OhpS9gQEIuw X-Google-Smtp-Source: AGHT+IF8vrt3iDMsTp8FQD00+Wgd0aeriRqxWBu5ziqeh5/TryrFovVfiBjdULShLu4v8n7OXpoelTNsWRK/hzNhICI= X-Received: by 2002:a05:622a:5e8e:b0:43f:fc3d:8c27 with SMTP id d75a77b69052e-441a91bbc5emr301331cf.23.1718220133977; Wed, 12 Jun 2024 12:22:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: James Y Knight Date: Wed, 12 Jun 2024 15:21:45 -0400 Message-ID: To: musl@lists.openwall.com Cc: "Ram Nalamothu (QUIC)" Content-Type: multipart/alternative; boundary="000000000000bbb14f061ab64c50" Subject: Re: [musl] Integer only print functions support in MUSL --000000000000bbb14f061ab64c50 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable According to LLVM sources (LLVM knows how to transform printf variants into iprintf variants), "iprintf and friends are only available on XCore, TCE, and Emscripten." I note that emscripten actually uses musl's printf implementation, and has added iprintf support as a downstream patch. On Wed, Jun 12, 2024 at 2:56=E2=80=AFPM Markus Wichmann = wrote: > Am Wed, Jun 12, 2024 at 05:29:59PM +0000 schrieb Ram Nalamothu (QUIC): > > Hi, > > > > On the subject line topic, is there a plan for integer only print > functions support in MUSL upstream? > > > > The newlib seems to support the same since 2004 [1] and one immediate > scenario using this capability is assert function [2] in the C library > itself which needs to print only the non-float types. > > > > Applications that use integer only print functions can benefit from thi= s > capability in terms of reduced code size by avoiding floating point suppo= rt > implementation in the linked print functions. > > > > I tried a quick search on the mailing list but couldn't find any > previous discussions on this topic. > > Would it make sense to have the similar support in MUSL as well? Would > the community be open to accept patches supporting integer only print > functions? > > > > Regards, > > Ram > > > > [1] https://sourceware.org/legacy-ml/newlib/2004/msg00577.html > > [2] > https://sourceware.org/git/?p=3Dnewlib-cygwin.git;a=3Dblob;f=3Dnewlib/lib= c/stdlib/assert.c#l58 > > Standard criteria for inclusion in musl have always been any kind of > standardization effort at all. Otherwise there is a risk of future > incompatible standardization. And iprintf() seems to be a newlib > exclusive; I cannot find any reference to this function outside of it. > > Ciao, > Markus > --000000000000bbb14f061ab64c50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
According to LLVM sources (LLVM knows how to transform pri= ntf variants into iprintf variants), "iprintf and friends are only ava= ilable on XCore, TCE, and Emscripten."

I note that = emscripten actually uses musl's printf implementation, and has added ip= rintf support as a downstream=C2=A0patch.



On We= d, Jun 12, 2024 at 2:56=E2=80=AFPM Markus Wichmann <nullplan@gmx.net> wrote:
Am Wed, Jun 12, 2024 at 05:29:59PM +0000 s= chrieb Ram Nalamothu (QUIC):
> Hi,
>
> On the subject line topic, is there a plan for integer only print func= tions support in MUSL upstream?
>
> The newlib seems to support the same since 2004 [1] and one immediate = scenario using this capability is assert function [2] in the C library itse= lf which needs to print only the non-float types.
>
> Applications that use integer only print functions can benefit from th= is capability in terms of reduced code size by avoiding floating point supp= ort implementation in the linked print functions.
>
> I tried a quick search on the mailing list but couldn't find any p= revious discussions on this topic.
> Would it make sense to have the similar support in MUSL as well? Would= the community be open to accept patches supporting integer only print func= tions?
>
> Regards,
> Ram
>
> [1] https://sourceware.org/legacy-ml/= newlib/2004/msg00577.html
> [2] https://sourceware.org/git/?p=3Dnewlib-cygwin.git;a=3Dblob;f=3Dnewlib/li= bc/stdlib/assert.c#l58

Standard criteria for inclusion in musl have always been any kind of
standardization effort at all. Otherwise there is a risk of future
incompatible standardization. And iprintf() seems to be a newlib
exclusive; I cannot find any reference to this function outside of it.

Ciao,
Markus
--000000000000bbb14f061ab64c50--