Liste des Groupes | Revenir à c arch |
Michael S <already5chosen@yahoo.com> writes:
On Wed, 11 Sep 2024 09:29:04 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
Josh Vanderhoof <x@y.z> writes:>
>
[how to write a portable, UB-free check if mempcy() intervals
overlap]It is legal to test for equality between pointers to different>
objects
Right. This observation is the key insight.
Real mode x86 C compilers operating in Large and Compact Models that
were popular on IBM-compatible PCs 30-40 years ago could have more
than one representation for the pointer to the same memory
location. If my memory serves me, the rules of pointers comparison
for equality were the same as rules of comparison for <>. In both
cases for reliable result pointers had to be explicitly normalized
(i.e. converted from 'far' to 'huge' or something like that).
>
It was long time ago and even back then I didn't use Large model
very often, so it's possible that I misremember. But if I remember
correctly, does it mean that those C compilers now would be
considered non-compliant?
The C standard was first ratified (by ANSI) in 1989. The rules
for pointer comparison were clarified in the C99 standard, but it
has always been true that pointers to the same object have to
compare equal.
C environments that have things like 'far' or 'huge' pointers,
etc, are not standard C but must have extensions so that they can
deal with the different kinds of pointers. Depending on how the
non-standard kinds of pointer worked, the implementation might or
might not be conforming. Most likely though it's a moot point
because once a program starts using an extension all the rules
can change, and the C standard allows that. It's only programs
that look like really standard C that have to do what the C
standard says (for the implementation to be conforming); any
code that declares a 'far' pointer or 'huge' pointer certainly
isn't standard C.
Les messages affichés proviennent d'usenet.