public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Martin Sebor <msebor@gmail.com>
To: Tuan Le Quang <lequangtuan6b@gmail.com>, gcc-patches@gcc.gnu.org
Subject: Re: [PATCH][gcc] Allow functions without C-style ellipsis to use format attribute
Date: Tue, 29 Jun 2021 13:56:47 -0600	[thread overview]
Message-ID: <f748cf32-df99-d17e-bc46-ebb9d27dc783@gmail.com> (raw)
In-Reply-To: <CALVAeY2ew9tiBeOWhT5Mo2cG4zRzV+bs-kK-JTyCseTM46Fazw@mail.gmail.com>

On 6/27/21 10:24 PM, Tuan Le Quang via Gcc-patches wrote:
> Hi,
> 
> Currently, format attribute can be used to do type-checking for arguments
> with respect to  a format string. However, only functions with a C-style
> ellipsis can use it.
> Supporting this attribute for non-variadic functions(functions without a
> C-style ellipsis) gives nice convenience especially when writing code in
> C++, we can use it for C++ variadic template functions like this
> 
> template<Args...args>
> __attribute__((format(printf, 1, 2))) void myPrint (const char * fmt,
> Args...args)

The main benefit of variadic functions templates over C vararg
functions is that they make use of the type system for type safety.
I'm not sure I see applying attribute format to them as a very
compelling use case.  (I'd expect the format string in a variadic
function template to use generic conversion specifiers, say %@ or
some such, and only let the caller specify things like flags, width
and precision but not type conversion specifiers).  Is there one
where relying on the type system isn't good enough?

> This patch will introduce these changes:
> 1. It is no longer an error simply to have a function with the format
> attribute but no C-style variadic arguments

I'm a little on the fence about this.  On the one hand it seems
unexpected to apply format checking to ordinary (non-variadic)
functions.  On the other, I can't think of anything wrong with it
and it even seems like it could be useful to specify a format for
a fixed number of arguments of fixed types.  Do you have an actual
use case for it or did it just fall out of the varaidic template
implementation?

> 2. Functions are subjected to warnings/errors as before, except errors
> mentioned in point 1 about not being variadic. For example, when a
> non-variadic function has wrong arguments, e.g
> __attribute__((format(printf, 1, 1))) or when being type-checked.
> 
> Note that behaviours of C-style variadic functions do not change, errors
> and warnings are given as before.
> 
> This patch does it by:
> 1.   Relaxing several conditions for format attribute:
>       -  Will only use POSARG_ELLIPSIS flag to call `get_constant` when
> getting attribute arguments of a variadic function
>       -  Relax the check for the last argument of the attribute (will not
> require an ellipsis argument)
>       -  (Before this patch) After passing the above check, current gcc will
> call `get_constant` to get the function parameter that the third attribute
> argument is pointing to. If POSARG_ELLIPSIS is set, `get_constant` will
> look for `...`. If not, `get_constant` will look for a C-style string. Note
> that POSARG_ELLIPSIS is set automatically for getting the third attribute
> argument.
>          (After this patch) POSARG_ELLIPSIS is set only when the function
> has C-style '...'. Now, if POSARG_ELLIPSIS is not set, `get_constant` will
> not check whether the third argument of format attribute points to a
> C-style string.
> 2.   Modifying expected outcome of a testcase in objc testsuite, where we
> expect a warning instead of an error
> 3.   Adding 2 test files
> 
> Successully bootstrapped and regression tested on x86_64-pc-linux-gnu.
> 
> Signed-off-by: Le Quang Tuan <lequangtuan6b@gmail.com>
> 
> gcc/c-family/ChangeLog:
> 
> * c-attribs.c (positional_argument): allow third argument of format
> attribute to point to parameters of any type if the function is not C-style
> variadic
> * c-format.c (decode_format_attr): read third argument with POSARG_ELLIPSIS
> only if the function has has a variable argument
> (handle_format_attribute): relax explicit checks for non-variadic functions
> 
> gcc/testsuite/ChangeLog:
> 
> * gcc.dg/format/attr-3.c: modify comment
> * objc.dg/attributes/method-format-1.m: errors do not hold anymore, a
> warning is given instead
> * g++.dg/warn/format9.C: New test with usage of variadic templates.
> * gcc.dg/format/attr-9.c: New test.
> 
> diff --git a/gcc/c-family/c-attribs.c b/gcc/c-family/c-attribs.c
> index 6bf492afcc0..7a17ce671de 100644
> --- a/gcc/c-family/c-attribs.c
> +++ b/gcc/c-family/c-attribs.c
> @@ -714,6 +714,11 @@ positional_argument (const_tree fntype, const_tree
> atname, tree pos,
>     return NULL_TREE;
>    }
> 
> +  /* For format attribute with argno >= 3, we don't expect any type
> +   */
> +  if (argno >= 3 && strcmp (IDENTIFIER_POINTER(atname), "format") == 0 &&
> !(flags & POSARG_ELLIPSIS ) )
> +    return pos;

Hardcoding knowledge of individual attributes in this function doesn't
seem very robust.  Avoiding that is the purpose of the flags argument.
I'd suggest adding a bit to the posargflags enum.

Also, at this point, (flags & POSARG_ELLIPSIS) should be zero as
a result of the test above (not shown) so repeating the test shouldn't
be necessary.

Martin

  reply	other threads:[~2021-06-29 19:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-28  4:24 Tuan Le Quang
2021-06-29 19:56 ` Martin Sebor [this message]
2021-07-05  6:38   ` Tuan Le Quang
2021-07-19 19:31     ` Martin Sebor
2021-07-28 21:12       ` Joseph Myers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f748cf32-df99-d17e-bc46-ebb9d27dc783@gmail.com \
    --to=msebor@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=lequangtuan6b@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).