Path: ...!news.mixmin.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Ben Bacarisse <ben.usenet@bsb.me.uk>
Newsgroups: comp.lang.c
Subject: Re: Recursion, Yo
Date: Mon, 15 Apr 2024 21:37:35 +0100
Organization: A noiseless patient Spider
Lines: 74
Message-ID: <87zftunz00.fsf@bsb.me.uk>
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>
	<uvjusj$ev88$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Mon, 15 Apr 2024 22:37:35 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="6f2b9767d6d5a3e2221fc1fe8acd049e";
	logging-data="514562"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+M8vHCKMT9wsHssDAxnpPKg3AZHIRxhhQ="
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:oJnyXbAkGsE755KLI60sDhix0n4=
	sha1:LwXdNLBrpppjB+RgZ3F2XDLlP+I=
X-BSB-Auth: 1.025398ef3d18478ef8ad.20240415213735BST.87zftunz00.fsf@bsb.me.uk
Bytes: 4915

bart <bc@freeuk.com> writes:

> On 15/04/2024 20: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.
>
> Implicit in every C non-void object pointer, is that it points to an
> element of an array, so that you access neighbouring elements via P+1, P-2,
> ++P and so on.
>
> That is the case whether or not P actually points within such a
> sequence.

No that is not implicit in every non-void object pointer.  In fact, it
is explicitly stated in the language standard that you /can't/ access
/anything/ via the "neighbouring" pointers except when the original is a
pointer into an array and those neighbouring elements are also in the
same array.

> That assumption appears to be missing from those other languages.

It's missing in C too.  Address arithmetic and access is permitted only
within an array.

> C itself doesn't seem that bothered; it just treats any isolated object
> that a pointer refers to, as though it was part of an imaginary 1-element
> array.

This is true, and it's not implicit -- it is explicitly stated in the
language standard.

-- 
Ben.