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=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID,
	DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI,NICE_REPLY_A,
	RCVD_IN_MSPIKE_H2,T_SCC_BODY_TEXT_LINE autolearn=ham
	autolearn_force=no version=3.4.4
Received: (qmail 14756 invoked from network); 6 Sep 2022 12:22:09 -0000
Received: from second.openwall.net (193.110.157.125)
  by inbox.vuxu.org with ESMTPUTF8; 6 Sep 2022 12:22:09 -0000
Received: (qmail 21793 invoked by uid 550); 6 Sep 2022 12:22:06 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 21761 invoked from network); 6 Sep 2022 12:22:06 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:references:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :from:to:cc:subject:date;
        bh=BOmdm56sDSyp2pPybReLb0ROGIGqRFteOd9aEwsVWco=;
        b=OcsWpzUBYxw+yN4jb5jvj4itCemaXpNdxJ0GW+bjp6f0GQdfvo3Z/ZdAM/uZ67II22
         tr9g6Zc3RfoHrKatFpZ+ufYEycgToiYLvud92SvArb1uQSBxf7ZaKE4wSA/+kIo8nILf
         Mp2+8qxpmsUUXPqwQMDdpWIs/YWIfxDphaQXrIFBwIyKo7/3/CfzikSHuBujmkE8MxjF
         PmnumvGj8KcePOBQQ/IHCCWpOz3Yc0m+Rfe1yeVPy5RU1+eVB/1FrFOXtlql8+SStXq2
         ow2nZFudfX0t2nVFT5DjEpQKa9+5C8sC2sRrqeWzOReTCK1LHzXpBPAdphJCs3Nd6Wwn
         MidA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20210112;
        h=content-transfer-encoding:in-reply-to:from:references:to
         :content-language:subject:user-agent:mime-version:date:message-id
         :x-gm-message-state:from:to:cc:subject:date;
        bh=BOmdm56sDSyp2pPybReLb0ROGIGqRFteOd9aEwsVWco=;
        b=nZSRO/Q5I4MoRLDGoC1zvWzqWjh9A8IHkA6mIUq6PliApc8uq3KkIFoRhQnvfgavJX
         XBOjq11CryCWYfM2Ss6qIj6+xn/IIOqoR4ihw1PcKgpKNeNH1DM0SU/lmrQSmfJXMo1W
         r9TI5DiVu+uMPGKmh5yfdQmHtev6GsqNTNEZtJctYmaLGw5sZ7OrgscPA0UhfRfX7J23
         OwmkxINy+3AD/7XUrF9mGUFFKNeCot2r5jyFlj0jkQKiyxo4vtK8dSC0je7G8otviz7s
         zXY55MmLiyvs5gbnf/u/nOosmdog+VglSwm9sEELfRsA157+x/E4p7wAIlxPGiqzJtfr
         MtSQ==
X-Gm-Message-State: ACgBeo09E97LV1f4oV7GnJtz9QVyvkLWk0K48sFDqmzbVZCgur89p6V9
	qp/DElb96T220Fk1PfO49ijU2LRuXcoV3g==
X-Google-Smtp-Source: AA6agR6V1uuE8AvIWwGkxLbwRwpN7v1YXvwHz7M3XpngM3f+TZdFh6dzwvZFw75L+xKykzzsVsfCEw==
X-Received: by 2002:a5d:620b:0:b0:228:8d5e:b55a with SMTP id y11-20020a5d620b000000b002288d5eb55amr5488389wru.625.1662466914452;
        Tue, 06 Sep 2022 05:21:54 -0700 (PDT)
Message-ID: <166c0b26-198a-91d3-08c9-ba135fc57065@gmail.com>
Date: Tue, 6 Sep 2022 14:21:52 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.0
Content-Language: en-US
To: musl@lists.openwall.com, Joakim Sindholt <opensource@zhasha.com>
References: <7bf9a30d-4ba8-1fe7-8c80-db99446db307@gmail.com>
 <6c1dfc63-b3e8-46a3-1db1-4d5bdf031086@gmail.com>
 <20220906141311.b8650027f3499c080f45b4fd@zhasha.com>
From: Gabriel Ravier <gabravier@gmail.com>
In-Reply-To: <20220906141311.b8650027f3499c080f45b4fd@zhasha.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [musl] ecvt(0, 0, ...) is broken

On 9/6/22 14:13, Joakim Sindholt wrote:
> On Tue, 6 Sep 2022 12:12:48 +0200, Gabriel Ravier <gabravier@gmail.com> wrote:
>> Executing ecvt(0, 0, &decpt, &sign) results in musl returning
>> "000000000000000".
>>
>> This seems highly likely to be a bug considering that glibc returns ""
>> and I see no plausible reasoning for musl's behavior that could be
>> justified by the standard.
> POSIX.1-2001 said:
>> The ecvt() function shall convert value to a null-terminated string of
>> ndigit digits (where ndigit is reduced to an unspecified limit
>> determined by the precision of a double) and return a pointer to the
>> string. The high-order digit shall be non-zero, unless the value is 0.
> The first part would imply that ndigit=0 should return the string "" but
> the second part makes no provision for a zero-digit-long string.
> I would say ndigit=0 is UB.
Wouldn't that then mean that any request call of fcvt with a small 
ndigits but very small value that isn't 0, as in my previous email, 
would also be UB (since if my logic is correct, the string cannot start 
with a 0 but it also cannot start with any other value, which forces it 
to be empty) ? That seems rather excessive...