public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/47634] Incorrect checking of attribute format printf on constructor of derived class with virtual base
Date: Sat, 07 May 2022 14:44:12 +0000	[thread overview]
Message-ID: <bug-47634-4-s79wyO1ztQ@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-47634-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47634

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Marek Polacek <mpolacek@gcc.gnu.org>:

https://gcc.gnu.org/g:0c723bb4be2a67657828b692997855afcdc5d286

commit r13-167-g0c723bb4be2a67657828b692997855afcdc5d286
Author: Marek Polacek <polacek@redhat.com>
Date:   Thu Mar 31 18:31:39 2022 -0400

    c, c++: attribute format on a ctor with a vbase [PR101833, PR47634]

    Attribute format takes three arguments: archetype, string-index, and
    first-to-check.  The last two specify the position in the function
    parameter list.  r63030 clarified that "Since non-static C++ methods have
    an implicit this argument, the arguments of such methods should be counted
    from two, not one, when giving values for string-index and first-to-check."
    Therefore one has to write

      struct D {
        D(const char *, ...) __attribute__((format(printf, 2, 3)));
      };

    However -- and this is the problem in this PR -- ctors with virtual
    bases also get two additional parameters: the in-charge parameter and
    the VTT parameter (added in maybe_retrofit_in_chrg).  In fact we'll end up
    with two clones of the ctor: an in-charge and a not-in-charge version (see
    build_cdtor_clones).  That means that the argument position the user
    specified in the attribute argument will refer to different arguments,
    depending on which constructor we're currently dealing with.  This can
    cause a range of problems: wrong errors, confusing warnings, or crashes.

    This patch corrects that; for C we don't have to do anything, and in C++
    we can use num_artificial_parms_for.  It would be wrong to rewrite the
    attributes the user supplied, so I've changed POS to be passed by
    reference so that we don't have to change all the call sites of
    positional_argument and we still get the default_conversion adjustment.

    Attribute format_arg is not affected, because it requires that the
    function returns "const char *" which will never be the case for cdtors.

            PR c++/101833
            PR c++/47634

    gcc/c-family/ChangeLog:

            * c-attribs.cc (positional_argument): Pass POS by reference.  Deal
            with FN being either a function declaration or function type.  Use
            maybe_adjust_arg_pos_for_attribute.
            * c-common.cc (check_function_arguments): Maybe pass FNDECL down to
            check_function_format.
            * c-common.h (maybe_adjust_arg_pos_for_attribute): Declare.
            (positional_argument): Adjust.
            * c-format.cc (get_constant): Rename to ...
            (validate_constant): ... this.  Take EXPR by reference.  Return
bool
            instead of tree.
            (handle_format_arg_attribute): Don't overwrite FORMAT_NUM_EXPR by
the
            return value of validate_constant.
            (decode_format_attr): Don't overwrite FORMAT_NUM_EXPR and
            FIRST_ARG_NUM_EXPR by the return value of validate_constant.
            (check_function_format): Adjust a parameter name.
            (handle_format_attribute): Maybe pass FNDECL down to
decode_format_attr.

    gcc/c/ChangeLog:

            * c-objc-common.cc (maybe_adjust_arg_pos_for_attribute): New.

    gcc/cp/ChangeLog:

            * tree.cc (maybe_adjust_arg_pos_for_attribute): New.

    gcc/ChangeLog:

            * tree-core.h (struct attribute_spec): Update comment for HANDLER.

    gcc/testsuite/ChangeLog:

            * g++.dg/ext/attr-format-arg1.C: New test.
            * g++.dg/ext/attr-format1.C: New test.
            * g++.dg/ext/attr-format2.C: New test.
            * g++.dg/ext/attr-format3.C: New test.

  parent reply	other threads:[~2022-05-07 14:44 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-07 14:50 [Bug c++/47634] New: " dan at randomdan dot homeip.net
2021-08-09 18:26 ` [Bug c++/47634] " pinskia at gcc dot gnu.org
2022-03-31 22:37 ` mpolacek at gcc dot gnu.org
2022-05-07 14:44 ` cvs-commit at gcc dot gnu.org [this message]
2022-05-07 14:59 ` mpolacek at gcc dot gnu.org

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=bug-47634-4-s79wyO1ztQ@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).