Un problème de taille

Palaiseau, le vendredi 18 décembre 2020

Après mise à jour de vg dans Debian Sid, les serveurs de compilation se sont mis en route pour construire les paquets à partir du code source. La compilation pour architecture amd64 s'est très bien passée ; ça tombe bien, c'est là que j'ai bien fait gaffe à ce que tout se passe bien. L'architecture arm64 n'est pas bien passée par contre, mais je m'y attendais un peu. Là où ça a coincé, c'est sur les architectures restantes, que je n'ai pas vérifié, notamment l'architecture i386 de grand papa. La compilation tombe en erreur sur :

bdsg/include/bdsg/internal/hash_map.hpp:121:33: error: static assertion failed: widest hashable type is size_t
  121 |         static_assert(sizeof(T) <= sizeof(size_t), "widest hashable type is size_t");
      |                       ~~~~~~~~~~^~~~~~~~~~~~~~~~~

Je n'ai pas recopié l'erreur complète, comme c'est issu de C++, il y en a pour treize lignes, mais elles sont tellement longues qu'il y en a pour des pages et des pages de bruit. Le type T est un modèle, du mot clé template, inféré à la compilation, correspondant dans ce cas précis à un type long long int. Soit le programme en C++ suivant :

#include <iostream>
int main (int argc, char ** argv)
{
	std::cout << "long long int = " << sizeof(long long int) << std::endl;
	std::cout << "size_t        = " << sizeof(size_t)        << std::endl;
	return 0;
}

long long int = 8
size_t        = 8

long long int = 8
size_t        = 4

C'est dommage, l'assertion statique est présente pour empêcher l'usage du type générique size_t si le type source est plus volumineux, et éviter ainsi les erreurs de hachage. Là, le long long int fait 64 bits, soit 8 octets, pendant que size_t n'en fait que 32 (4 octets).

À la lecture du code source, j'ai l'impression que l'idée initiale était d'être capable de prendre en charge les différentes tailles d'entier avec le même algorithme, en passant tout en type générique size_t, en assumant que les types entiers n'étaient jamais plus gros que size_t en 64 bits. Il y a encore pas mal d'ajustement que je voudrais effectuer sur la procédure de construction du paquet, mais je me demande si je n'ai pas sous les yeux un candidat qui va bientôt sauter de l'archive 32 bits. Ce qui me chiffonne, c'est que je me demande ce que ce genre de code peut bien attendre d'autres architectures qu'amd64 ; à moins que le problème initial n'ait rien à voir avec l'architecture de processeur, et soit entièrement lié au fonctionnement en boite noire de la programmation orientée objet, pour éviter au gentil camarade de se prendre les pieds dans le tapis avec un algorithme de hachage qui ne hache pas comme il faut dans certaines conditions.

	Name	Last modified	Size
	Parent Directory		-