Path: csiph.com!news.swapon.de!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 12:00:30 -0700
Organization: None to speak of
Lines: 50
Message-ID: <87bk6asb75.fsf@nosuchdomain.example.com>
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>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Mon, 15 Apr 2024 21:00:44 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="73a59417e165fb25aa14cac8ac742e2a"; logging-data="478112"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/HSAJqBCRReygnGVsBLEzx"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
Cancel-Lock: sha1:P/x9TZV8TElbgHj2dR9TJs2w8T8= sha1:P8LtUW2StKMBI5z06/5hwTHkQos=
Xref: csiph.com comp.lang.c:384349

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.

-- 
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 */