[4og]

Problem

Two tests in zip_iterator_test.cpp fail on QNX x86_64 but pass on Linux x86_64 and QNX aarch64:

• container_test_basics.swap (all three container types)
• container_test_bi_directional.use_in_stl_algorithm_with_bidirectional_iterator_requirement (both bidirectional container types)

Both tests zipped two offset views of the same container {a, b, c} = {1.2, 3.4, 5.6}.
The two zipped positions therefore referred to (a, b) and (b, c), sharing the storage of b.
Both tests then swapped dereferenced zip iterators, swap(*iter1, *iter2) directly and std::reverse via iter_swap.

Root cause

zip_iterator::operator* returns a zipped_tuple_like holding references to the underlying elements.
Its ADL swap delegates to std::swap on the underlying std::tuple, which swaps the tuple elements pairwise: swap(a, b) and swap(b, c).
Since both modify b, the result depends on the order of these two swaps:

Element swap order	(a, b, c) afterwards
swap(a, b), then swap(b, c)	(3.4, 5.6, 1.2)
swap(b, c), then swap(a, b)	(5.6, 1.2, 3.4)

libstdc++ swaps tuple elements left to right.
libc++ (used by QNX) implements tuple::swap as std::__swallow(__tuple_leaf<I, T>::swap(...)...), i.e. the element swaps are function arguments whose evaluation order is unspecified in C++17.
The QNX GCC aarch64 build evaluates them left to right, the x86_64 build right to left, which yields 5.6 instead of the expected 3.4.

More fundamentally, (a, b) and (b, c) cannot be exchanged as independent records: after a true exchange, b would have to hold both the original a and the original c.
The tests relied on unspecified behavior rather than on a property of zip_iterator.

Fix

The two mutating tests now zip two independent containers ({1.2, 3.4} and {5.6, 7.8}), so every zipped position refers to distinct storage and the swap result is independent of element swap order.
Coverage is kept or improved:

• swap still checks both swapping iterator objects and swapping the dereferenced zipped values, and now asserts both positions after each step.
• The bidirectional test still runs std::reverse and now asserts both positions afterwards.

The zip_iterator implementation is unchanged.
Read-only tests (find, post_increment, copy_assignment, etc.) keep using offset views of a single container, since overlap is harmless there.

Alternatives considered

• Force left-to-right element swaps in zipped_tuple_like's swap. This would make results identical across platforms, but the outcome for overlapping ranges would still not be a meaningful exchange. It would change library behavior only to satisfy an invalid test assumption.
• Disable the tests on QNX x86_64 or weaken assertions. Loses coverage without addressing the order-dependent setup.

[github-actions]

Documentation preview for this pull request is available at:
pr-658: https://eclipse-score.github.io/baselibs/pr-658/

[Ehrja]

The change looks fine to me. To my knowledge there is no known usecase for using the same container in overlapping manner within zip-iterator within BMW scope.

From the analysis it really originates in unspecified execution-order and thus relies on underlying "system-libraries".
I just wonder whether it is possible to "emit" the semantics of "this quirk" to users in a better way than just encoded in existing unit-tests. So maybe a doxy-note or something in public-api 🤔