All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org
Subject: Re: [PATCH 0/4] varargs functions with __attributes__(())
Date: Tue, 11 Jun 2024 08:17:08 -0700	[thread overview]
Message-ID: <xmqqcyony0ej.fsf@gitster.g> (raw)
In-Reply-To: <20240611081735.GI3248245@coredump.intra.peff.net> (Jeff King's message of "Tue, 11 Jun 2024 04:17:35 -0400")

Jeff King <peff@peff.net> writes:

> On Sat, Jun 08, 2024 at 11:37:43AM -0700, Junio C Hamano wrote:
>
>> There are several varargs functions that take either NULL-terminated
>> list of parameters, or printf-like format followed by list of
>> parameters, that are not declared as such with __attributes__(()).
>> 
>> Adding such a missing attribute to trace2_region_enter_printf()
>> revealed that an existing call to it was trying to format a value of
>> type size_t using "%d", which is not such an excellent idea.  Other
>> functions that were lacking attributes fortunately did not have any
>> broken existing callers.
>
> Great, I am happy to see these. I assume you found them all by grepping?
>
> I wonder if there is a way to convince the compiler (or coccinelle) to
> complain about any varargs function that does not have one of our
> usual annotations. It's possible to have other conventions (e.g., an
> "int" up front specifying the number of entries) but in practice I doubt
> we would ever use one.
>
> Still, I suspect the answer is probably "no", there is not an easy way
> to do it.

I just went from grepping for fixed "...)" in *.[ch] files.  I do
admit I wished some form of automation, but didn't come up with one.

I was happy that the exercise found a real bug ;-)  I started it
only as a clean-up topic.

      reply	other threads:[~2024-06-11 15:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-08 18:37 [PATCH 0/4] varargs functions with __attributes__(()) Junio C Hamano
2024-06-08 18:37 ` [PATCH 1/4] __attribute__: trace2_region_enter_printf() is like "printf" Junio C Hamano
2024-06-10  7:01   ` Patrick Steinhardt
2024-06-10 16:15     ` Junio C Hamano
2024-06-08 18:37 ` [PATCH 2/4] __attribute__: remove redundant attribute declaration for git_die_config() Junio C Hamano
2024-06-08 18:37 ` [PATCH 3/4] __attribute__: mark some functions with LAST_ARG_MUST_BE_NULL Junio C Hamano
2024-06-08 18:37 ` [PATCH 4/4] __attribute__: add a few missing format attributes Junio C Hamano
2024-06-11  8:17 ` [PATCH 0/4] varargs functions with __attributes__(()) Jeff King
2024-06-11 15:17   ` Junio C Hamano [this message]

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=xmqqcyony0ej.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.