public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Xi Ruoyao <xry111@xry111.site>
Cc: Martin Uecker <uecker@tugraz.at>,
	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:57:56 +0100	[thread overview]
Message-ID: <ZXBv1FtIDHkgNfD5@tucnak> (raw)
In-Reply-To: <ae5ace46c444e40d4b1a2cbe189d672421520895.camel@xry111.site>

On Wed, Dec 06, 2023 at 08:31:12PM +0800, Xi Ruoyao wrote:
> On Wed, 2023-12-06 at 13:24 +0100, Jakub Jelinek wrote:
> > I wonder if this part isn't too pedantic or more of a code style.
> > Some packages fail to build with this with -Werror because they do
> >   struct S *p = calloc (sizeof (struct S), 1);
> > or similar.  It is true that calloc arguments are documented to be
> > nmemb, size, but given sufficient alignment (which is not really different
> > between either order of arguments) isn't it completely valid to allocate
> > char array with sizeof (struct S) elements and then store a struct S object
> > into it?
> 
> In PR112364 Martin Uecker has pointed out the alignment may be different
> with the different order of arguments, per C23 (N2293).  With earlier
> versions of the standard some people believe the alignment should not be
> different, while the other people disagree (as the text is not very
> clear).

I can understand implementations which use smaller alignment based on
allocation size, but are there any which consider for that just the second
calloc argument rather than the product of both arguments?
I think they'd quickly break a lot of real-world code.
Further I think
"size less than or equal to the size requested"
is quite ambiguous in the calloc case, isn't the size requested in the
calloc case actually nmemb * size rather than just size?

	Jakub


  reply	other threads:[~2023-12-06 12:58 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 [this message]
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

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=ZXBv1FtIDHkgNfD5@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --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).