Terje Mathisen <terje.mathisen@tmsw.no> writes:

> David Brown wrote:
>
>> On 04/04/2023 07:39, Anton Ertl wrote:
>>
>>> One reason for comparing pointers is if you want to implement
>>> memmove(), as discussed in the article.
>>
>> memmove(), and other standard library functions, are part of the
>> implementation. They were traditionally implemented in assembly,
>> and only later in C. But as part of the implementation, they can
>> use features that are implementation-specific - there was never any
>> need or intention that such functions should be implementable in
>> portable standards-compliant C. The language never had any need to
>> support writing an efficient memmove() in C - it gave you a
>> ready-made memmove() function so that implementing it yourself is
>> not necessary.
>
> Is pointer comparison implementation defined (ID) or UB?

Any two pointers (including null pointers) may be compared for
equality or inequality. The result is well defined: either
they are the same, or they aren't, and the implementation has
nothing to say about it.

For relational comparisons, the two pointers must be pointers into
(or one past) the same array object. All other pointer pairs
(including either or both being a null pointer) fall into UB
if relationally compared.

> If it is ID, then I can write my own version of memmove() (or similar
> ops) on any given compiler, as long as I do it the way that particular
> compiler have defined it, right?
>
> If it is UB, then that's impossible, you have to step outside of the C
> standard to implement it, and do so in a way that makes it impossible
> for the compiler to discover that you have done so. :-)

This conclusion is wrong. It is possible to implement memmove() in
standard C using only well-defined comparisons. (I suppose I should
add that some people would object based on the belief that the means
of doing so is horrible, which I don't necessarily share, but either
way I still think it's worth pointing out that it's possible, and
even feasible.)

On 7/20/23 21:50, Tim Rentsch wrote:
> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>
>> David Brown wrote:
>>
>>> On 04/04/2023 07:39, Anton Ertl wrote:
>>>
>>>> One reason for comparing pointers is if you want to implement
>>>> memmove(), as discussed in the article.
>>>
>>> memmove(), and other standard library functions, are part of the
>>> implementation. They were traditionally implemented in assembly,
>>> and only later in C. But as part of the implementation, they can
>>> use features that are implementation-specific - there was never any
>>> need or intention that such functions should be implementable in
>>> portable standards-compliant C. The language never had any need to
>>> support writing an efficient memmove() in C - it gave you a
>>> ready-made memmove() function so that implementing it yourself is
>>> not necessary.
>>
>> Is pointer comparison implementation defined (ID) or UB?
>
> Any two pointers (including null pointers) may be compared for
> equality or inequality. The result is well defined: either
> they are the same, or they aren't, and the implementation has
> nothing to say about it.
>
> For relational comparisons, the two pointers must be pointers into
> (or one past) the same array object. All other pointer pairs
> (including either or both being a null pointer) fall into UB
> if relationally compared.
>
>> If it is ID, then I can write my own version of memmove() (or similar
>> ops) on any given compiler, as long as I do it the way that particular
>> compiler have defined it, right?
>>
>> If it is UB, then that's impossible, you have to step outside of the C
>> standard to implement it, and do so in a way that makes it impossible
>> for the compiler to discover that you have done so. :-)
>
> This conclusion is wrong. It is possible to implement memmove() in
> standard C using only well-defined comparisons. (I suppose I should
> add that some people would object based on the belief that the means
> of doing so is horrible, which I don't necessarily share, but either
> way I still think it's worth pointing out that it's possible, and
> even feasible.)

Programming in C or speaking natural language is fundamentally
about communication. If you want to be sure that the receiver
understands what you are saying, speak clearly and make no
assumptions about the receiver's knowledge.

Always program a strict subset of C here, no clever stuff
and most of it works first time, apart from typos. Saves
so much time in the long run. Can't be bothered doing
it right to start is the reason why we have so much bad code
to put up with...

Chris

chrisq <devzero@nospam.com> writes:

> On 7/20/23 21:50, Tim Rentsch wrote:

[regarding pointer comparison and memmove()]

>> It is possible to implement memmove() in standard C using only
>> well-defined comparisons. (I suppose I should add that some
>> people would object based on the belief that the means of doing
>> so is horrible, which I don't necessarily share, but either way I
>> still think it's worth pointing out that it's possible, and even
>> feasible.)
>
> Programming in C or speaking natural language is fundamentally
> about communication. If you want to be sure that the receiver
> understands what you are saying, speak clearly and make no
> assumptions about the receiver's knowledge.
>
> Always program a strict subset of C here, no clever stuff
> and most of it works first time, apart from typos. Saves
> so much time in the long run. Can't be bothered doing
> it right to start is the reason why we have so much bad code
> to put up with...

I don't necessarily agree with your advice, but whether
I do or not has no bearing on my comments.