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

On 17/07/2024 19:53, BGB wrote:

On 7/17/2024 6:38 AM, Bart wrote:

On 13/07/2024 10:39, BGB wrote:
>

But, as I see it, no real point in arguing this stuff (personally, I have better stuff to be doing...).

>
We all do. But this group seems to be about arguing about pointless stuff and you might come here when you want a respite from proper work.
>
However (here I assume you've gone back to Quake but that other interested parties might be reading this), consider the program below.
>

 I got back to debugging...

To be clear - you are talking about debugging your compiler here, yes?

 Ironically, one of the big bugs I ended up finding was related to internal struct handling "leaking through" and negatively effecting stuff.
 say:
   typedef struct foo_s foo_t;  // don't care what it contains for now.
    foo_t arr[...];
   foo_t temp;
   int i, j;
   ...
   temp=arr[i];
   arr[i]=arr[j];
   arr[j]=temp;
 Internally, it would load a reference to arr[i] into temp, but then this location would get overwritten before the third assignment happened, causing the incorrect contents to be copied to arr[j].
 For now, have ended up changing stuff such that any struct-assignment (for structs in the "by-ref" category) to a local variable will instead copy the contents to the memory location associated with that struct.

How could it possibly mean anything else?  Structs in C are objects - contiguous blocks of bytes interpreted by a type.  Assigning them will mean copying those bytes.  Pretending the language sometimes means structs and sometimes means magical auto-dereferencing pointers to structs is simply wrong.
If "foo_t" is 2000 bytes long, then "foo_t temp" makes a 2000 byte space in your local variables (the stack, on virtually every platform) and "temp = arr[i];" does a 2000 byte memcpy().  The same thing applies if "foo_t" is 2 bytes long, or 2 megabytes long.  And if there is a stack overflow making "temp", that's the programmer's problem.
It is only once that is all working properly and reliably that you can begin to think about optimisation - code that gives the same observable behaviour "as if" you had direct translation, but is more efficient. Maybe your target architecture has a way to make a "memswap()" function that is more efficient than two "memcpy()" calls, and you can use that.
And it is only when the direct translation is working properly that you can start to think of improving user convenience.  Perhaps you could allocate large temporary objects in non-stack memory somewhere to avoid stack overflows.  I don't think that is a good idea, but it's a possibility.  Giving compiler warnings about large stack objects is a much better solution IMHO.