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

On 09/07/2024 17:54, Michael S wrote:

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.

I would mind a great deal if it used a heap.  Heaps support out-of-order allocation and deallocation - this can mean significant overhead in space and very non-deterministic behaviour.  A secondary stack would be a different matter entirely, and is much more reasonable.  There are some kinds of code where a secondary stack would be a useful structure. (I've worked with microcontrollers where there was a separate return stack and data stack.)  But I'd want to know about it!
It makes a lot more sense to me to simply have compiler flags that complain if you have stack objects that are too big.  (How much is "too big" will vary depending on your target.)

The main advantage however is not performance, but reducing the
severity of damage caused by buffer overrun bugs.
 

There are much better ways to deal with that than randomly using a heap for some objects and not others.

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.
 

Just use a more appropriate language that has better run-time checking when this is your prime concern.  And if you are using C, keep things small and simple so that the programmer, the static analysis tools, and the code reviewer can all confirm that there are no buffer overflows.