Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: else ladders practice
Date: Fri, 22 Nov 2024 14:11:51 +0000
Organization: A noiseless patient Spider
Lines: 134
Message-ID: <vhq3f7$16o2d$1@dont-email.me>
References: <3deb64c5b0ee344acd9fbaea1002baf7302c1e8f@i2pn2.org>
 <vgdt36$2r682$2@paganini.bofh.team> <vge8un$1o57r$3@dont-email.me>
 <vgpi5h$6s5t$1@paganini.bofh.team> <vgtsli$1690f$1@dont-email.me>
 <vhgr1v$2ovnd$1@paganini.bofh.team> <vhic66$1thk0$1@dont-email.me>
 <vhins8$1vuvp$1@dont-email.me> <vhj7nc$2svjh$1@paganini.bofh.team>
 <vhje8l$2412p$1@dont-email.me> <vhl1up$5vdg$1@dont-email.me>
 <vhlg53$8lff$1@dont-email.me> <vhnasl$l8h5$1@dont-email.me>
 <vhnj3n$mk94$1@dont-email.me> <vhpuod$3mlgf$2@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 22 Nov 2024 15:11:51 +0100 (CET)
Injection-Info: dont-email.me; posting-host="373db3823bc9f838b9ab0e3fdedd4a11";
	logging-data="1269837"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18TlF1fxkJk6otVC4qyccsK"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:1FarJRNecLkjP6OJUY+z7gvBfHs=
Content-Language: en-GB
In-Reply-To: <vhpuod$3mlgf$2@paganini.bofh.team>
Bytes: 5237

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.