Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.lang.c
Subject: Re: Recursion, Yo
Date: Mon, 15 Apr 2024 22:39:37 +0200
Organization: A noiseless patient Spider
Lines: 85
Message-ID: <uvk3ab$fsvh$1@dont-email.me>
References: <uut24f$2icpb$1@dont-email.me> <uv5gfd$qum1$1@dont-email.me>
 <uv5lgl$s6uj$1@dont-email.me> <uv61f6$v1jm$1@dont-email.me>
 <uv68ok$11080$1@dont-email.me> <uv7a8n$18qf8$3@dont-email.me>
 <uv867l$1j8l6$1@dont-email.me> <_zSRN.161297$m4d.144795@fx43.iad>
 <20240411075825.30@kylheku.com> <r8TRN.114606$Wbff.54968@fx37.iad>
 <uva6ep$24ji7$1@dont-email.me> <uvah1j$26gtr$1@dont-email.me>
 <uvao71$27qit$1@dont-email.me> <uvb9r4$2c31v$1@dont-email.me>
 <uvcing$2kbfj$6@dont-email.me> <20240413203303.000001f9@yahoo.com>
 <878r1grgn3.fsf@bsb.me.uk> <20240414032902.00003dc8@yahoo.com>
 <uvj8qp$9s2q$1@dont-email.me> <87frvmsk6u.fsf@nosuchdomain.example.com>
 <87jzkypo7s.fsf@bsb.me.uk> <87bk6asb75.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 15 Apr 2024 22:39:40 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0881d93770e909c422c4476978404946";
	logging-data="521201"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/zMaIwK3d40UbPdrA+nwG1"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:fkoaEnf/R9NA2ophx5JHscQNmGo=
X-Enigmail-Draft-Status: N1110
In-Reply-To: <87bk6asb75.fsf@nosuchdomain.example.com>
Bytes: 5408

On 15.04.2024 21:00, Keith Thompson wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>>> On 14.04.2024 02:29, Michael S wrote:
>> <Algol 68 code elided>
>>>>> It looks closer to C than to Pascal, i.e. pointer can point to any
>>>>> object rather than just to dynamically allocated object.
>>>>
>>>> The major difference is that they are closely bound to the type.
>>>> In that respect they are more like Pascal pointers. C pointers
>>>> open the can of issues with arithmetic on pointer values. You
>>>> don't find that in Pascal or Algol 68.
>>> [...]
>>>
>>> How are C pointers not "closely bound to the type"?
>>
>>   int i = 42;
>>   memcpy(&i, &(float){3.14}, sizeof i);
>>   printf("%d\n", i);
>>
>> That looks like a pretty loose association between pointer and object
>> type to me.  This is not an accident or an unintended loophole.  It's by
>> design.
>>
>> Certainly every pointer value in C has an associated type, but the
>> intention is that this association can be changed by pointer type
>> conversion as needed.
>>
>> You often /have/ to make us of this.  For example, when calling qsort,
>> you will usually change the association between the pointer and the
>> pointed-to type (void) in order to do the comparison.  And C does not
>> even insist that you change it back to the original pointed-to type as
>> you can legally write a comparison function for, say, float data that
>> uses the representation as "raw" bytes.
> 
> OK.  The way I'd describe it is that C (non-void) pointers *are*
> "closely bound to the type", but in addition C provides operations,
> particularly pointer casts and implicit conversions to and from void*,
> that can override that binding.
> 
> Janis mentioned pointer arithmetic.  I wouldn't say that overrides the
> type binding; it merely provides a set of operations, that some other
> languages lack, for constructing a pointer value from another pointer
> value.  I don't know whether Janis meant that to be an example of not
> being closely bound to the type, or as a distinct statement.

It's no "lacking operations". It's a deliberate design for safety.

Rutishauser spoke (for Algol 60) about "leaving the Can of Pandora
closed". And F. L. Bauer noted that "Pascal opened the Can of Pandora
but put a fly screen over it". (Pascal can here be seen as an example
of one language, other HLLs have done it basically the same way.)

The rest can probably be derived from inspecting how various HLL do
support that and how C does it. Basically,
- memory of appropriate size is allocated
- the reference is assigned to the variable
- access is done without address modification possible
You may consider that from a low level perspective a missing feature,
but I call it not unnecessarily opening a can of issues. - Examples...

Pascal:     var p : ^T;  new (p);  p^.x := ... ;

Algol 68:   REF T p = HEAP T;  x OF p := ... ;

Simula 67:  REF (T) p;  p :- new T;  p.x := ... ;


C:          T * p = (T *) malloc (sizeof(T));  (p+42) = ... ;

            Yes, you would not write that, but you can.
            And all sorts of casts makes it even worse.
            In the other languages mentioned you can't.

C++: with it's 'new' (and also 'malloc') is somewhat ambivalent.

(Disclaimers:
1. Code snippets may contain errors.
2. I don't know of newer C standards, just suppose that nothing
   substantial has changed in this respect to fix the inherent
   original C design criteria.)

Janis