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.1 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI,NICE_REPLY_A, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7258 invoked from network); 16 Apr 2023 13:21:20 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 16 Apr 2023 13:21:20 -0000 Received: (qmail 25898 invoked by uid 550); 16 Apr 2023 13:21:14 -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 25777 invoked from network); 16 Apr 2023 13:21:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1681651261; x=1684243261; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=724+Ffx2iNZKlkIihw6VXH8W69mFXHbzqlhXZtuFS78=; b=VNCZTPoJ7PEnYGg8cxUKRL5IYyOGTxPSTYRKSOSetxnWUS1NpRWrIUlPdXLUKWKoKk kqotk22uoze56vI3/d2VVcf+27RbwgQiqllw88Zz6BEWAfjAwqZzpXXA0+HyfrWK2C9K LILahLxMwB8tdUGBZJ8eND59r4khfUZaSH/QWWTKThCEuDRpfcvAU9m9d6uGo8Obt8jN wv9EZNB5fkQMpYS1x/549j07JZF2p4mjpRwaQcEg/Cgb8D4v6wypXYQMFJCRY3e4b9t/ 25U/62CCgTKD+/AJ4Ou6Gr7e1mV9GmdpBroDgKLjUjFuSirvEMQygJ19im7ZGw2AvVeX 4aEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681651261; x=1684243261; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=724+Ffx2iNZKlkIihw6VXH8W69mFXHbzqlhXZtuFS78=; b=dymQpzxIINwsk4gu6Ry8HHPCVJ5JhZIXmGyu54KWYFcj87iCE+etZ/I/ejtOSNZsoZ dS70BbHxxHcpte5kZ4lsPaCoNm3L+6BSZKPJycOzQ+rX4rzEg76MRaYM0dHt6x6CwT6f ulm1CVajd+8XuMN7VGDqwSKA8TlU2OzWkKQtWcnHzpD3L7Q6lWFcO/jWULOWBv3ZXf0W 6m4wIxWxo74+xHvwq4bNTbybe08gWNPB/k8SUCZ0htn9Euo3UorXMjZBcTHcvB+iKpUZ 79eOTUxVhbwVOux+4+LBy+GugCqFBWgEb7FeD4DTqwWqMC5AC/XC/KyARYzqEpZb5m0e dtEg== X-Gm-Message-State: AAQBX9cQo8NV/uUqGMd8MKSCy+23D5goDsMEg09ZulAQWPgOGKC6X6/g 5Jt5X0R7jS71nH+UW8Z350YCJUnz5kCqew== X-Google-Smtp-Source: AKy350a8m9/kON6f/OXJ/7w4Yl8YgIpmWbMVZYdXcCRLeAixUuWbzrscxqTL9JEu+9NcMl5c7zE2hg== X-Received: by 2002:a5d:63cf:0:b0:2f4:6270:48d3 with SMTP id c15-20020a5d63cf000000b002f4627048d3mr3687601wrw.0.1681651261365; Sun, 16 Apr 2023 06:21:01 -0700 (PDT) Message-ID: <30474c83-aa94-05d3-b7d6-aea3a0bd4e63@gmail.com> Date: Sun, 16 Apr 2023 15:20:59 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.1 Content-Language: en-US To: =?UTF-8?B?SuKCkeKCmeKCmyBHdXN0ZWR0?= Cc: musl@lists.openwall.com References: <20220908163649.634728-1-gabravier@gmail.com> <20230416085113.1c88ebe5@inria.fr> From: Gabriel Ravier In-Reply-To: <20230416085113.1c88ebe5@inria.fr> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [musl] [PATCH v2 1/1] vfprintf: support C2x %b and %B conversion specifiers On 4/16/23 08:51, Jₑₙₛ Gustedt wrote: > Gabriel, > it also seems to me that ... > > on Sat, 15 Apr 2023 14:28:28 +0200 you (Gabriel Ravier > ) wrote: > >> + /* This buffer is used for integer conversions. As such, it needs >> + * to be able to contain the full representation of a number in base 2, >> + * 8, 10 or 16, with base 2 having the largest possible requirement of >> + * as many characters as the amount of bits in the largest >> possible >> + * integer type */ >> + char buf[sizeof(uintmax_t)*CHAR_BIT]; > ... here a `+3` seems to be in order to take care of the `0[bx]` > prefix and a terminating null byte. This buffer is only used specifically for storing converted digits, and is never used to store the alternative form, and never contains a null terminator either as the code knows the used length and never passes the buffer to a function that doesn't do so, so from what I can see these objections are wrong (in fact it wouldn't make much sense to store the prefix in that buffer given that the code also has to handle the possibility of extremely large 0-padding that goes between the prefix and the converted digits). Though perhaps the comment could be improved, I suppose it could be confusing... > > Thanks > Jₑₙₛ >