From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) by sourceware.org (Postfix) with ESMTPS id AB897386102F for ; Wed, 24 Mar 2021 19:39:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org AB897386102F Received: by mail-wm1-x32c.google.com with SMTP id k128so11141352wmk.4 for ; Wed, 24 Mar 2021 12:39:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=NmtSl7FgxKu8xSBVC13FwkktKbzQt6Jo2frNzfUR4C0=; b=kWZ1uDyjhzBwgGlnsZjMvBRgoIP949CP0w20uYIuhkuN2kQwZBSVyv2S5WO8Twv2rq wvprFx2VtZ/q0nF0P6JOBu/OPi4uFfjPEuInh1R1QeHV0s0GL/1Roo1YyKu6JYQojcVI NezsOsYRbytURslbVEE72xZHERVuC5Hxv92xg36ygH4EDIsXPtjcrj1ZOWD8gI5vtv2g 9U/v5x6BUgwn4SW+8IcF4tLprp2MzlVpYuqKGbpax4B8QVU22Je9Ql3O7vc+g4xchw4P XN9HK5bdQrgs8Fs9/7aVvrkuwHXYryE3ZvNsMc7suIYyGHZe4u3ztvOLvVhhDjqoVYE5 KqMQ== X-Gm-Message-State: AOAM532pBf8k6q+9I0Tf/B5uQQVZxiNtfA5sWjCXbfTquHW0OK62zIy1 j8iJi8Gs0M0a9KAoSSbVbKlGCpHhcuI= X-Google-Smtp-Source: ABdhPJwkwlKhQpEyiXBTMQB7rbdYMMI4jsg9vBho3C6Xo+UTVM62TyTGr37jy80r7qXay0R7RNvYqA== X-Received: by 2002:a1c:bd55:: with SMTP id n82mr4405879wmf.3.1616614784803; Wed, 24 Mar 2021 12:39:44 -0700 (PDT) Received: from [192.168.0.160] ([170.253.36.171]) by smtp.gmail.com with ESMTPSA id b15sm3900914wmd.41.2021.03.24.12.39.44 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 24 Mar 2021 12:39:44 -0700 (PDT) Subject: Re: printf_arginfo_size_function error handling From: "Alejandro Colomar (man-pages)" To: GNU C Library References: Message-ID: <865294a1-542d-3ed2-314d-c8abf9b5df12@gmail.com> Date: Wed, 24 Mar 2021 20:39:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Mar 2021 19:39:47 -0000 Hi, On 3/24/21 8:30 PM, Alejandro Colomar (man-pages) wrote: > Hi, > > On 3/24/21 5:39 PM, Alejandro Colomar (man-pages) wrote: >> Hi, >> >> I've been re-reading the docs for printf_register_specifier(), and >> there's something in an example code that doesn't make much sense: >> >> >> [[ >> >> int >> print_widget_arginfo (const struct printf_info *info, size_t n, >> int *argtypes) >> { >> /* We always take exactly one argument and this is a pointer to the >> structure.. */ >> if (n > 0) >> argtypes[0] = PA_POINTER; >> return 1; >> } >> >> ]] >> >> In the code above there is a check that n>0, but: >> >> What can a user do if n<=0 ? There's no error reporting method, is there? >> And, is it possible for such a case to happen? What to do there? >> >> I think either using an assert() or not checking at all might make more >> sense (depending on how possible is n<=0 to happen). The current check >> continues as if everything was fine, just without setting argtypes[0], >> so if there's an error, it will be carried to some future stage, where >> nasal daemons might unexpectedly happen. > > After reading the sources, I see a few things: > > - There's an undocumented error handling mechanism: you can return a > negative value to signify an error. However, I couldn't understand what > exactly happens when you report an error. Does the printf_function get > called? > > - n seems to be nonnegative: it's called in three places > (, > , and stdio-common/printf-prs.c:94), > and all of them make sure n is positive, so the test in the example is > useless. > > - I could't understand how n>1 could be used from reading the > (obfuscated) sources. And there's no documentation. Is it really > supported? And how? Would you mind documenting that? Maybe with an > example that makes use of the non-obvious features of this API. > > - Even though printf_arginfo_size_function supposedly handles the case > of n>1, printf_function doesn't seem to handle it. It gets the array of > arguments, but it doesn't get the size of the array, so the only valid > assumption is that the array is of size 1; anything else might fail > silently. If you use the misterious feature of multiple arguments for a > single specifier, how do you guarantee that you'll receive as many slots > in the array as you want? By checking it in the arginfo function and > reporting an error if n is not big enough? Will that guarantee that > printf_function is not called? Again, I see no documentation at all > about this, and the sources are not the easiest to read. > If I understood correctly, the 3rd parameter argtypes of printf_arginfo_size_function is an array, right? So a more friendly prototype would be typedef int printf_arginfo_size_function(const struct printf_info *info, size_t n, int argtypes[static n], int *size); Also, what about the last 'size' argument of printf_arginfo_size_function? Is it an array or just a pointer? If it's a pointer, how do you pass the size of each of the arguments you set in argtypes? Is the following prototype correct (I'm guessing)?: typedef int printf_arginfo_size_function(const struct printf_info *info, size_t n, int argtypes[static n], int size[static n]); Thanks, Alex -- Alejandro Colomar Linux man-pages comaintainer; https://www.kernel.org/doc/man-pages/ http://www.alejandro-colomar.es/