From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mailrelay.tugraz.at (mailrelay.tugraz.at [129.27.2.202]) by sourceware.org (Postfix) with ESMTPS id 52DC83858C36 for ; Fri, 27 Oct 2023 14:53:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 52DC83858C36 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=tugraz.at Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tugraz.at ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 52DC83858C36 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=129.27.2.202 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698418416; cv=none; b=d4o2xe3D+I3oMTdYizJsyupFYCaSIU635GtUtxWZyeAQymx9IfPDUzpoiISXb9scPj/XgN0bAWuasalSu7km48u/QB5fpinRFCQs41huoyojnwB1gCJdqZxR7kkQeOibEafVLZiRTUyOzHOpZs6vf/KPMR73fEGWXc3SgQvVi10= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1698418416; c=relaxed/simple; bh=vYuAo9m0HSScl1TYVfy+ZkbUSSrHF1ChJ4XB/DzFwPA=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=p9uFNRYWHqrc5VN/aBpf6ZH/1f9/Vfkn6GfxCKCWnB+R3EV1YQML9QnELn4Fb4Tecvf8MaXIcer2jz3gfmti1+6tR2X0k8JS8/rGI8BHiYN9PBCW0sPJgfmAoiMPV/OUM71kfQ1e6oJaXtNQlEpn5VQjyAn2hDz8p/flSVlsG4A= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from vra-169-157.tugraz.at (vra-169-157.tugraz.at [129.27.169.157]) by mailrelay.tugraz.at (Postfix) with ESMTPSA id 4SH5JM1qBhz3wcG; Fri, 27 Oct 2023 16:53:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tugraz.at; s=mailrelay; t=1698418404; bh=xr0/m9dO290enYbexkyiHz13v8572Fx2sHFog4oKRjY=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=RgrG01x6eitmox8SYpxXJJoemiziUdghciFD5utf4WWv7WtJfMuhiX2PWD+IwxlEn vr57jYqaM3WNNVh2uLDQ4+DK1c16BE8FE0O++8a5YMb0KH1Wk5Kdaqdl2uIXCBlZFW 7RcHEB//PfWpOSBmgcse0rQcNtIHM5r4UrYAN2gU= Message-ID: Subject: Re: HELP: Will the reordering happen? Re: [V3][PATCH 0/3] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896) From: Martin Uecker To: Qing Zhao Cc: Kees Cook , Siddhesh Poyarekar , Richard Biener , Joseph Myers , Jakub Jelinek , gcc Patches , "isanbard@gmail.com" Date: Fri, 27 Oct 2023 16:53:22 +0200 In-Reply-To: References: <92426898-afa7-47f7-9aab-5f2114eb826a@gotplt.org> <05d65224067ff72124d94b6b5274f14d013b64af.camel@tugraz.at> <2A78AF07-4E87-43DD-9C1B-23A15C43A8E4@oracle.com> <202310251504.6DE743979@keescook> <947881C6-7040-4C73-8A81-0F364D0DF469@oracle.com> <202310251529.296AB019@keescook> <2df236317429b1c08fa11982d4e65a6b798bd4c6.camel@tugraz.at> <202310260851.B3719E6928@keescook> <6e07e4da210b3ee53e3bae5b18949a9d62b2a0b0.camel@tugraz.at> <081064A6-7104-4A12-8D11-BB3FA6EA55DF@oracle.com> <5a95d30d4e7cbfa71e24935072412c6d6ff55324.camel@tugraz.at> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 X-TUG-Backscatter-control: G/VXY7/6zeyuAY/PU2/0qw X-Spam-Scanner: SpamAssassin 3.003001 X-Spam-Score-relay: -0.4 X-Scanned-By: MIMEDefang 2.74 on 129.27.10.117 X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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: Am Freitag, dem 27.10.2023 um 14:32 +0000 schrieb Qing Zhao: >=20 > > On Oct 27, 2023, at 3:21 AM, Martin Uecker wrote: > >=20 > > Am Donnerstag, dem 26.10.2023 um 19:57 +0000 schrieb Qing Zhao: > > > I guess that what Kees wanted, ""fill the array without knowing the a= ctual final size" code pattern=E2=80=9D, as following: > > >=20 > > > > > struct foo *f; > > > > > char *p; > > > > > int i; > > > > >=20 > > > > > f =3D alloc(maximum_possible); > > > > > f->count =3D 0; > > > > > p =3D f->buf; > > > > >=20 > > > > > for (i; data_is_available() && i < maximum_possible; i++) { > > > > > f->count ++; > > > > > p[i] =3D next_data_item(); > > > > > } > > >=20 > > > actually is a dynamic array, or more accurately, Bounded-size dynamic= array: ( but not a dynamic allocated array as we discussed so far) > > >=20 > > > https://en.wikipedia.org/wiki/Dynamic_array > > >=20 > > > This dynamic array, also is called growable array, or resizable array= , whose size can=20 > > > be changed during the lifetime.=20 > > >=20 > > > For VLA or FAM, I believe that they are both dynamic allocated array,= i.e, even though the size is not know at the compilation time, but the siz= e > > > will be fixed after the array is allocated.=20 > > >=20 > > > I am not sure whether C has support to such Dynamic array? Or whether= it=E2=80=99s easy to provide dynamic array support in C? > >=20 > > It is possible to support dynamic arrays in C even with > > good checking, but not safely using the pattern above > > where you derive a pointer which you later use independently. > >=20 > > While we could track the connection to the original struct, > > the necessary synchronization between the counter and the > > access to the buffer is difficult. I do not see how this > > could be supported with reasonable effort and cost. > >=20 > >=20 > > But with this restriction in mind, we can do a lot in C. > > For example, see my experimental (!) container library > > which has vector type. > > https://github.com/uecker/noplate/blob/main/test.c > > You can get an array view for the vector (which then > > also can decay to a pointer), so it interoperates nicely > > with C but you can get good bounds checking. > >=20 > >=20 > > But once you derive a pointer and pass it on, it gets > > difficult. But if you want safety, you just have to=20 > > to simply avoid this in code.=20 >=20 > So, for the following modified code: (without the additional pointer =E2= =80=9Cp=E2=80=9D) >=20 > struct foo > { > size_t count; > char buf[] __attribute__((counted_by(count))); > }; >=20 > struct foo *f; > int i; =20 >=20 > f =3D alloc(maximum_possible); > f->count =3D 0; >=20 > for (i; data_is_available() && i < maximum_possible; i++) { > f->count ++; =20 > f->buf[i] =3D next_data_item(); > } =20 >=20 > The support for dynamic array should be possible?=20 With the design we discussed this should work because __builtin_with_access (or whatever) it reads: f =3D alloc(maximum_possible); f->count =3D 0; for (i; data_is_available() && i < maximum_possible; i++) { f->count ++; =20 __builtin_with_access(f->buf, f->count)[i] =3D next_data_item(); } =20 >=20 >=20 > >=20 > > What we could potentially do is add restrictions so=20 > > that the access to buf always has to go via x->buf=20 > > or you get at least a warning. >=20 > Are the following two restrictions to the user enough: >=20 > 1. The access to buf should always go via x->buf,=20 > no assignment to another independent pointer=20 > and access buf through this new pointer. Yes, maybe. One could also try to be smarter. For example, one warn only when &f->buf is assigned to another pointer and one of the following conditions is fulfilled: - the pointer escapes from the local context=C2=A0 - there is a store to f->counter in the local context that does not dominate &f->buf. Then Kees' example would work too in most cases. But I would probably wait until we have some initial experience with this feature. Martin > 2. User need to keep the synchronization between > the counter and the access to the buffer all the time. >=20 >=20