From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by sourceware.org (Postfix) with ESMTPS id 6177A3858D33 for ; Tue, 8 Aug 2023 16:18:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6177A3858D33 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id 60BD81F853; Tue, 8 Aug 2023 16:18:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1691511520; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=QxEFnz4YtHWCRIPAfdQ5FNO0E4aVz6P2mkt06+7nWPo=; b=pDKtORnSwoIVJ5twzv34UqnOoTUpS4xtsXqS0vVfaABwa3W/Ei6bzVsIVHaSJ+hmLa1X5j zyJbOfqizorYo1LoSdHtTTG7oV8k4iMj4rACny/WdYviMtUb3aSChDckg5rdlb4Gntc+nU iJy3OMHqqzLhaBCgThps4E8Me+b+vlE= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1691511520; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=QxEFnz4YtHWCRIPAfdQ5FNO0E4aVz6P2mkt06+7nWPo=; b=M1sYHb/csyWvf5VNaLVX6RxX0HpLC4vscCA3N4oh+VUozfndwfArJpVdXaK0Vhfk/RujOw 6rZAPkF5Q74VkTCw== Received: from wotan.suse.de (wotan.suse.de [10.160.0.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id F292D2C142; Tue, 8 Aug 2023 16:18:39 +0000 (UTC) Received: by wotan.suse.de (Postfix, from userid 10510) id E727B696E; Tue, 8 Aug 2023 16:18:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by wotan.suse.de (Postfix) with ESMTP id E575B6957; Tue, 8 Aug 2023 16:18:39 +0000 (UTC) Date: Tue, 8 Aug 2023 16:18:39 +0000 (UTC) From: Michael Matz To: Martin Uecker cc: Kees Cook , Qing Zhao , joseph@codesourcery.com, richard.guenther@gmail.com, jakub@redhat.com, gcc-patches@gcc.gnu.org, siddhesh@gotplt.org, isanbard@gmail.com Subject: Re: [V2][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896) In-Reply-To: <5f76638c8cfca7611e955ef9fadacfd7f8dca0fb.camel@tugraz.at> Message-ID: References: <20230804194431.993958-1-qing.zhao@oracle.com> <202308070858.D2FB43E@keescook> <5f76638c8cfca7611e955ef9fadacfd7f8dca0fb.camel@tugraz.at> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="-1609957120-632246744-1691511519=:25429" X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1609957120-632246744-1691511519=:25429 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Hello, On Tue, 8 Aug 2023, Martin Uecker via Gcc-patches wrote: > There at least three different size expression which could > make sense. Consider > > short foo { int a; short b; char t[]; };  > > Most people seem to use > > sizeof(struct foo) + N * sizeof(foo->t); > > which for N == 3 yields 11 bytes on x86-64 because the formula > adds the padding of the original struct. There is an example > in the  C standard that uses this formula. > > > But he minimum size of an object which stores N elements is > > max(sizeof (struct s), offsetof(struct s, t[n])) > > which is 9 bytes. But should it really? struct sizes should usually be a multiple of a structs alignment, and if int is 4-aligned only size 12 would be correct. I don't see why one should deviate from that general rule for sizes for FAM structs. (I realize that the above is not about sizeof(), but rather bdos/bos, but I think it's fairly useful that both agree when possbible). Say, if you were to allocate an array of such struct foos, each having 3 elements in foo.t[]. You need to add 12 bytes to go to the next array element, not 9. (Of course arrays of FAM-structs are somewhat meh, but still). It's true that you would be allowed to rely on only 9 bytes of those 12 bytes (the rest being padding), so perhaps it's really the right answer for __bos, but, hmm, 12 seems to be "more correct" to my guts :-) Ciao, Michael. ---1609957120-632246744-1691511519=:25429--