Other classes that have native_handle/typesizes.cc tests have
native_type_handle defined as a pointer type, and the pointed-to type is
native_handle, the type of the single data member of the class (*).  It
thus makes sense to check that the single data member and the enclosing
class type have the same size and alignment: a pointer to the enclosing
type should also be a valid pointer to its single member.

(*) this single data member is actually inherited or enclosed in another
class, but let's not get distracted by this irrelevant detail.

std::thread, however, does not follow this pattern.  Not because the
single data member is defined as a direct data member of a nested class,
rather than inherited from another class.  The key difference is that it
does not use native_type_handle's pointed-to type as the single data
member, it rather uses native_type_handle directly as the type of the
single data member.

On GNU/Linux, and presumably on most platforms, native_handle_type =
__gthread_t is not even a pointer type.  This key difference would have
been obvious if remove_pointer<T> rejected non-pointer types, but that's
not the case.  When given __gthread_t -> pthread_t -> unsigned long int,
remove_pointer<T>::type is T, so we get unsigned long int back.  The
test works because there's no pointer type to strip off.

However, on a platform that defines __gthread_t as a pointer type, we
use that pointer type as native_type_handle and as the type for the
single data member of std::thread.  But then, the test compares size and
alignment of that type with those of the type obtained by removing one
indirection level.  We're comparing properties of different, unrelated
types.  Unless the pointed-to type happens to have, by chance, the size
and alignment of a pointer, the test will fail.


IOW, the test is no good: it's not testing what it should, and wherever
it passes, it's by accident.

In order to test what it should, we'd need to use an alternate test
function that does not strip off one indirection level from
native_handle_type, if the test is to remain.

Should I introduce such an alternate test function and adjust the test,
or just remove the broken test?

Or should we change std::thread::native_handle_type to __gthread_t*,
while keeping unchanged the type of the single data member
std::thread::id::_M_thread?

Thanks in advance,

-- 
Alexandre Oliva, freedom fighter  he/him   https://FSFLA.org/blogs/lxo
Be the change, be Free!                 FSF Latin America board member
GNU Toolchain Engineer                        Free Software Evangelist
Hay que enGNUrecerse, pero sin perder la terGNUra jamás - Che GNUevara

Reply via email to