Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Recursion, Yo
Date: Mon, 15 Apr 2024 14:25:00 -0700
Organization: None to speak of
Lines: 67
Message-ID: <877cgys4ib.fsf@nosuchdomain.example.com>
References: <uut24f$2icpb$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>
	<uvk3ab$fsvh$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Mon, 15 Apr 2024 23:25:01 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="73a59417e165fb25aa14cac8ac742e2a";
	logging-data="535702"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19Gj7J13hJTwNkXoj/0vjGn"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:VIPozOs9zFGbQvg1eeNfELKcO8Q=
	sha1:snloncIzHiSZMMkLghpEvo38i34=
Bytes: 4610

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> 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.

My use of the word "lack" wasn't meant as a value judgement.

Certainly C allows the association of a pointer with the type of the
object it points to be overridden.  I'd still say (again) that C
non-void pointers are "closely bound to the type" -- closely, but not
irrevocably.

Many more type-strict languages permit similar overriding of that
association, perhaps with a more explicit syntax (see "unsafe" in Rust,
"Unchecked_Conversion" in Ada).

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */