Date: Fri, 02 Dec 2022 08:48:30 -0800
On Friday, 2 December 2022 01:31:31 PST Marcin Jaczewski via Std-Discussion
wrote:
> > Yes. If it helps, the difference has existed since standardization: the
> > comparison is undefined in C89 and unspecified in C++98, so it might be
> > tricky to discover the rationale.
> >
> > Perhaps you could ask SG22 whether they know the cause of the divergence,
> > and whether they're interested in resolving it.
> This could be required by segmented memory and Far Pointer in 16-bit
> architectures.
That only explains why they aren't defined. It doesn't explain why one is
unspecified and the other UB.
We can reason on the consequence: the C standard allows the implementation to
crash if you try to order two pointers from different arrays. If that freedom
had to be reserved, it might be because some old architecture required some
calculation that would result in a fault or trap if the two pointers weren't
from the same array.
I can't think of any such architecture. The closest I can come to is the 16-
bit protected mode of the 80286, with __huge pointers: if the compiler
generated a segment descriptor that wasn't valid then proceeded to load that
into a segment register, it would crash. I don't know if this has ever
existed, though: __huge pointers existed in 16-bit real mode and were gone in
32-bit protected mode, and it's a generation of programming I completely
skipped. The more likely scenario is an overflow trap in the calculations, as
opposed to a memory layout constraint.
Either way, C++ said that while the compiler isn't required to produce a
reliable result, it can't crash or go off the rails either. It must produce a
comparison result and the code continues from there.
wrote:
> > Yes. If it helps, the difference has existed since standardization: the
> > comparison is undefined in C89 and unspecified in C++98, so it might be
> > tricky to discover the rationale.
> >
> > Perhaps you could ask SG22 whether they know the cause of the divergence,
> > and whether they're interested in resolving it.
> This could be required by segmented memory and Far Pointer in 16-bit
> architectures.
That only explains why they aren't defined. It doesn't explain why one is
unspecified and the other UB.
We can reason on the consequence: the C standard allows the implementation to
crash if you try to order two pointers from different arrays. If that freedom
had to be reserved, it might be because some old architecture required some
calculation that would result in a fault or trap if the two pointers weren't
from the same array.
I can't think of any such architecture. The closest I can come to is the 16-
bit protected mode of the 80286, with __huge pointers: if the compiler
generated a segment descriptor that wasn't valid then proceeded to load that
into a segment register, it would crash. I don't know if this has ever
existed, though: __huge pointers existed in 16-bit real mode and were gone in
32-bit protected mode, and it's a generation of programming I completely
skipped. The more likely scenario is an overflow trap in the calculations, as
opposed to a memory layout constraint.
Either way, C++ said that while the compiler isn't required to produce a
reliable result, it can't crash or go off the rails either. It must produce a
comparison result and the code continues from there.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DCAI Cloud Engineering
Received on 2022-12-02 16:48:34