Re: else ladders practice

On 22/11/2024 12:51, Waldek Hebisch wrote:

Bart <bc@freeuk.com> wrote:

>
   int main(void) {
      int a;
      int* p = 0;
      a = *p;
  }
>
Here's what happens with my C compiler when told to interpret it:
>
   c:\cx>cc -i c
   Compiling c.c to c.(int)
   Error: Null ptr access
>
Here's what happens with gcc:
>
   c:\cx>gcc c.c
   c:\cx>a
   <crashes>
>
Is there some option to insert such a check with gcc? I've no idea; most
people don't.

 I would do
 gcc -g c.c
gdb a.out
run
 and gdb would show me place with bad access.  Things like bound
checking array access or overflow checking makes a big difference.
Null pointer access is reliably detected by hardware so no big
deal.  Say what you 'cc' will do with the following function:
 int
foo(int n) {
     int a[10];
     int i;
     int res = 0;
     for(i = 0; i <= 10; i++) {
         a[i] = n + i;
     }
     for(i = 0; i <= 10; i++) {
         res += a[i];
     }
     res;
}
 Here gcc at compile time says:
 foo.c: In function ‘foo’:
foo.c:15:17: warning: iteration 10 invokes undefined behavior [-Waggressive-loop-optimizations]
    15 |         res += a[i];
       |                ~^~~
foo.c:14:18: note: within this loop
    14 |     for(i = 0; i <= 10; i++) {
       |                ~~^~~~~

My 'cc -i' wouldn't detect it. The -i tells it to run an interpreter on the intermediate code. Within the interpreter, some things are easily checked, but bounds info on arrays doesn't exist. (The IL supports only pointer operations, not high level array ops.)
That would need intervention at an earlier stage, but even then, the design of C makes that difficult. First, because array types like int[10] decay to simple pointers, and ones represented by types like int* don't have bounds info at all. (I don't support int[n] params and few people use them anyway.)
In my static language, it would be a little easier because an int[10] type doesn't decay; the info persists. C's int* would be ref[]int, still unbounded so has the same problem.
However the language also allows slices, array pointers that include a length, so those can be used for bounds checking. But then, it's not really needed in that case, since you tend to write loops like this:
    func foo(slice[]int a)int =
        for x in a do              # iterate over values
           ....
        for i in a.bounds do       # iterate over bounds
           ....
Apart from that, I have a higher level, interpreted language does do full bounds checking, so algorithms can be tested with that then ported to the static language, a task made simpler by them using the same syntax. I just need to add type annotations.
Getting back to 'cc -i', if I apply it to the program here, it gives an error:
   c:\cx>type c.c
   #include <stdio.h>
   int fred() {}
   int main(void) {
       printf("%d\n", fred());
   }
   c:\cx>cc -i c
   Compiling c.c to c.(int)
   PCL Exec error: RETF/SP mismatch: old=2 curr=1   seq: 7
If I try it with gcc, then nothing much happens:
   c:\cx>gcc c.c
   c:\cx>a
   1
If optimised, it shows 0 instead of 1, both meaningless values. It's a good thing the function wasn't called 'launchmissile()'.
Trying it with my language:
   c:\mx>type t.m
   func fred:int =
   end
   proc main =
       println fred()
   end
   c:\mx>mm -i t
   Compiling t.m to t.(int)
   TX Type Error:
   ....
   Void expression/return value missing
It won't compile it, and without needing to figure out which obscure set of options is needed to give a hard error.