Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: technology discussion =?UTF-8?Q?=E2=86=92?= does the world need
 a "new" C ?
Date: Tue, 9 Jul 2024 18:54:06 +0300
Organization: A noiseless patient Spider
Lines: 67
Message-ID: <20240709185406.0000734f@yahoo.com>
References: <v66eci$2qeee$1@dont-email.me>
	<v67gt1$2vq6a$2@dont-email.me>
	<v687h2$36i6p$1@dont-email.me>
	<871q48w98e.fsf@nosuchdomain.example.com>
	<v68dsm$37sg2$1@dont-email.me>
	<87wmlzvfqp.fsf@nosuchdomain.example.com>
	<v6ard1$3ngh6$4@dont-email.me>
	<v6b0jv$3nnt6$1@dont-email.me>
	<v6c298$3tko2$1@dont-email.me>
	<v6c688$3uf4o$1@dont-email.me>
	<v6jhvb$1drd6$2@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Tue, 09 Jul 2024 17:53:42 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="563505b595a11e4e07a72bd290784cde";
	logging-data="1383167"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/+c8hj2fLA/5nbwBkz3XPAEvIIhdkN6pE="
Cancel-Lock: sha1:CzdIjglX1xSMRW5TAjcpJJ4ngwU=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 3974

On Tue, 9 Jul 2024 16:37:31 +0200
David Brown <david.brown@hesbynett.no> wrote:

> On 06/07/2024 21:33, BGB wrote:
> >=20
> > In my compiler (BGBCC), such an internal pointer exists for arrays
> > and structures in the local stack frame.
> >=20
> > No separate pointer exists inside of things like structs, where, as
> > can be noted, the array exists at a fixed size and location.
> >=20
> >=20
> > So, eg:
> >  =C2=A0 void Foo()
> >  =C2=A0 {
> >  =C2=A0=C2=A0=C2=A0=C2=A0 int a[100];
> >  =C2=A0=C2=A0=C2=A0=C2=A0 ...
> >  =C2=A0 }
> >=20
> > There is both the space for 100 integers reserved in the stack
> > frame, and a variable 'a' which exists as an implicit pointer to
> > that location.
> >=20
> >=20
> > But, say:
> >  =C2=A0 void Foo()
> >  =C2=A0 {
> >  =C2=A0=C2=A0=C2=A0=C2=A0 int a[8192];
> >  =C2=A0=C2=A0=C2=A0=C2=A0 ...
> >  =C2=A0 }
> >=20
> > There is no space reserved on the stack, and the array is instead=20
> > allocated dynamically (from the heap). In this case, the "a"
> > variable exists as a pointer to that location in memory.
> >=20
> > Similar treatment also applies to structs.
> >  =20
>=20
>=20
> The C standard does not require a stack or say how local data is=20
> implemented, it just gives rules for the scope and lifetime of
> locals. However, I would be surprised and shocked to find a compiler
> I was using allocate local data on the heap in some manner.  If I
> have an array as local data, it is with the expectation that it is
> allocated and freed trivially (an add or subtract to the stack
> pointer, typically combined with any other stack frame).  If I want
> something on the heap, I will use malloc and put it on the heap.
>=20
> Such an implementation as yours is not, I think, against the C
> standards=20
> - but IMHO it is very much against C philosophy.
>=20

I wouldn't mind if my ABI/compiler allocates all big local objects
together with all local VLA either on separate secondary stack or even
on heap. Such strategy will improve locality of reference for primary
stack. So, despite higher management overhead, it could sometimes be
advantageous even for performance.
The main advantage however is not performance, but reducing the
severity of damage caused by buffer overrun bugs.

Although if "security" is a primary concern then one would want
stricter policy than the one outlined above. I.e. not only big objects,
but small object as well should be allocated away from primary stack as
long as their address participate in pointer arithmetic that can't be
proven safe by static analysis.