Re: technology discussion → does the world need a "new" C ?

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

On 06/07/2024 21:33, BGB wrote:

 
In my compiler (BGBCC), such an internal pointer exists for arrays
and structures in the local stack frame.
 
No separate pointer exists inside of things like structs, where, as
can be noted, the array exists at a fixed size and location.
 
 
So, eg:
   void Foo()
   {
      int a[100];
      ...
   }
 
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.
 
 
But, say:
   void Foo()
   {
      int a[8192];
      ...
   }
 
There is no space reserved on the stack, and the array is instead
allocated dynamically (from the heap). In this case, the "a"
variable exists as a pointer to that location in memory.
 
Similar treatment also applies to structs.
 

 
 
The C standard does not require a stack or say how local data is
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.
 
Such an implementation as yours is not, I think, against the C
standards
- but IMHO it is very much against C philosophy.
 

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.