public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Eric Gallager <egall@gwmail.gwu.edu>
To: Martin Uecker <uecker@tugraz.at>
Cc: Jakub Jelinek <jakub@redhat.com>, Xi Ruoyao <xry111@xry111.site>,
	gcc-patches@gcc.gnu.org,  Joseph Myers <joseph@codesourcery.com>,
	Marek Polacek <polacek@redhat.com>
Subject: Re: [C PATCH, v2] Add Walloc-size to warn about insufficient size in allocations [PR71219]
Date: Wed, 6 Dec 2023 13:00:43 -0500	[thread overview]
Message-ID: <CAMfHzOs31u84xts=R2yfuWRNw4Kmk0JtO6dyVWyrbLi88ebMbA@mail.gmail.com> (raw)
In-Reply-To: <d16930cb51065d066bce197f9bd977b44b8b6d8f.camel@tugraz.at>

On Wed, Dec 6, 2023 at 10:13 AM Martin Uecker <uecker@tugraz.at> wrote:
>
> Am Mittwoch, dem 06.12.2023 um 16:01 +0100 schrieb Jakub Jelinek:
> > On Wed, Dec 06, 2023 at 03:56:10PM +0100, Martin Uecker wrote:
> > > > That would be my preference because then the allocation size is
> > > > correct and it is purely a style warning.
> > > > It doesn't follow how the warning is described:
> > > > "Warn about calls to allocation functions decorated with attribute
> > > > @code{alloc_size} that specify insufficient size for the target type of
> > > > the pointer the result is assigned to"
> > > > when the size is certainly sufficient.
> > >
> > > The C standard defines the semantics of to allocate space
> > > of 'nmemb' objects of size 'size', so I would say
> > > the warning and its description are correct because
> > > if you call calloc with '1' as size argument but
> > > the object size is larger then you specify an
> > > insufficient size for the object given the semantical
> > > description of calloc in the standard.
> >
> > 1 is sizeof (char), so you ask for an array of sizeof (struct ...)
> > chars and store the struct into it.
>
> If you use
>
> char *p = calloc(sizeof(struct foo), 1);
>
> it does not warn.
>
> >
> > > > We have the -Wmemset-transposed-args warning, couldn't we
> > > > have a similar one for calloc, and perhaps do it solely in
> > > > the case where one uses sizeof of the type used in the cast
> > > > pointer?
> > > > So warn for
> > > > (struct S *) calloc (sizeof (struct S), 1)
> > > > or
> > > > (struct S *) calloc (sizeof (struct S), n)
> > > > but not for
> > > > (struct S *) calloc (4, 15)
> > > > or
> > > > (struct S *) calloc (sizeof (struct T), 1)
> > > > or similar?  Of course check for compatible types of TYPE_MAIN_VARIANTs.
> > >
> > > Yes, although in contrast to -Wmeset-transposed-args
> > > this would be considered a "style" option which then
> > > nobody would activate.  And if we put it into -Wextra
> > > then we have the same situation as today.
> >
> > Well, the significant difference would be that users would
> > know that they got the size for the allocation right, just
> > that a coding style says it is better to put the type's size
> > as the second argument rather than first, and they could disable
> > that warning separately from -Walloc-size and still get warnings
> > on (struct S *) calloc (1, 1) or (struct S *) malloc (3) if
> > sizeof (struct S) is 24...
>
> Ok.
>
> Note that another limitation of the current version is that it
> does not warn for
>
> ... = (struct S*) calloc (...)
>
> with the cast (which is non-idiomatic in C).

Note that -Wc++-compat encourages the cast, for people who are trying
to make their code compilable as both C and C++.

> This is also
> something I would like to address in the future and would be
> more important for the C++ version.  But for this case it
> should probably use the type of the cast and the warning
> needs to be added somewhere else in the FE.
>
>
> Martin
>

      reply	other threads:[~2023-12-06 18:00 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-18 21:26 Martin Uecker
2023-10-31 18:44 ` [PING] " Martin Uecker
2023-10-31 22:19   ` Joseph Myers
2023-11-01 15:37     ` Martin Uecker
2023-11-01 20:21       ` Joseph Myers
2023-11-02 13:58 ` [committed] c: Add missing conditions in Walloc-size to avoid ICEs [PR112347] Uecker, Martin
2023-12-06 12:24 ` [C PATCH, v2] Add Walloc-size to warn about insufficient size in allocations [PR71219] Jakub Jelinek
2023-12-06 12:31   ` Xi Ruoyao
2023-12-06 12:57     ` Jakub Jelinek
2023-12-06 13:34       ` Martin Uecker
2023-12-06 13:43         ` Martin Uecker
2023-12-06 14:21         ` Jakub Jelinek
2023-12-06 14:30           ` Siddhesh Poyarekar
2023-12-06 14:41             ` Jakub Jelinek
2023-12-06 14:43               ` Siddhesh Poyarekar
2023-12-06 14:56           ` Martin Uecker
2023-12-06 15:01             ` Jakub Jelinek
2023-12-06 15:10               ` Martin Uecker
2023-12-06 18:00                 ` Eric Gallager [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='CAMfHzOs31u84xts=R2yfuWRNw4Kmk0JtO6dyVWyrbLi88ebMbA@mail.gmail.com' \
    --to=egall@gwmail.gwu.edu \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=polacek@redhat.com \
    --cc=uecker@tugraz.at \
    --cc=xry111@xry111.site \
    /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).