Sujet : Re: Computer architects leaving Intel...
De : anton (at) *nospam* mips.complang.tuwien.ac.at (Anton Ertl)
Groupes : comp.archDate : 10. Sep 2024, 09:19:32
Autres entêtes
Organisation : Institut fuer Computersprachen, Technische Universitaet Wien
Message-ID : <2024Sep10.101932@mips.complang.tuwien.ac.at>
References : 1 2 3 4 5 6
User-Agent : xrn 10.11
George Neuner <
gneuner2@comcast.net> writes:
On Sun, 08 Sep 2024 15:36:39 GMT, anton@mips.complang.tuwien.ac.at
(Anton Ertl) wrote:
1) At first I thought that yes, one could just check whether there is
an overlap of the memory areas. But then I remembered that you cannot
write such a check in standard C without (in the general case)
exercising undefined behaviour; and then the compiler could eliminate
the check or do something else that's unexpected. Do you have such a
check in mind that does not exercise undefined behaviour in the
general case?
>
The result of comparing pointers to two elements of the same array is
defined. Cast to (char*), both src and dst can be considered to point
to elements of the [address space sized] char array at address zero.
Yes, that would be reasonable. Unfortunately, "optimizations" that
assume that undefined behaviour does not happen are not justified by
assigning reasonable meaning to language constructs, but by giving
only the little meaning to language constructs that the standard
requires, and in case of unequality comparisons between pointers to
different objects, the C standard does not define a meaning for that.
All of gcc, clang and MSVC seem happy with this.
But the next version of gcc or clang might see such a check and decide
to bite you.
One can cast the pointers into an uintptr_t, and try to do the check
there. AFAIK the result would be implementation-defined, but on an
architecture with a flat address space it's unlikely that they will
find a way to compile the code in a different way than the programmer
intended without making "relevant" programs slower.
- anton
-- 'Anyone trying for "industrial quality" ISA should avoid undefined behavior.' Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>