Nlohmann/json: Bug De Comparaison Mixte

Salut les développeurs et passionnés de code ! Aujourd'hui, on plonge dans un sujet qui peut sembler technique, mais qui est super important pour éviter des surprises désagréables dans vos projets utilisant la bibliothèque nlohmann/json. On va parler d'un bug de comparaison mixte qui peut affecter la manière dont la librairie traite les nombres, particulièrement quand on mélange des entiers signés et non signés. Imaginez, vous pensez que votre code fait une comparaison simple, mais nlohmann/json vous sort un résultat mathématiquement faux. Ça peut arriver, et c'est précisément ce qu'on va décortiquer ensemble pour que vous soyez au taquet !

Le cœur du problème : quand les nombres unsigned dépassent les limites signées

Le hic, les amis, c'est que la librairie nlohmann/json, dans certaines situations, a du mal à comparer correctement un nombre non signé (number_unsigned) qui dépasse la valeur maximale d'un entier signé 64 bits (INT64_MAX) avec un nombre entier signé (number_integer). Ce bug se manifeste principalement avec les opérateurs de comparaison comme == (égal à) et < (inférieur à). Le problème vient du fait que lorsque le nombre non signé est trop grand, sa conversion en type entier signé pour la comparaison tourne mal. Il est interprété comme un nombre négatif, ce qui inverse complètement la logique de comparaison et mène à des résultats erronés.

Ce comportement inattendu n'est pas isolé à une fonction spécifique de l'API. Non, messieurs, il semble s'agir d'un souci au niveau du cœur de l'implémentation des comparaisons mixtes dans la librairie. Que vous construisiez vos objets JSON directement, que vous assigniez des valeurs, que vous insériez des éléments dans des tableaux, ou que vous utilisiez json::parse(), le problème peut refaire surface. C'est dans le fichier include/nlohmann/json.hpp, plus précisément dans les branches mixtes du JSON_IMPLEMENT_OPERATOR que le bât blesse. Les développeurs ont identifié que le passage d'un number_unsigned (dans la plage [INT64_MAX + 1, UINT64_MAX]) à un number_integer_t peut le faire basculer dans le domaine des négatifs, brisant ainsi la sémantique de la comparaison.

Pour illustrer, considérons les branches de code incriminées :

else if (lhs_type == value_t::number_unsigned && rhs_type == value_t::number_integer)
{
    return static_cast<number_integer_t>(lhs.m_data.m_value.number_unsigned) op rhs.m_data.m_value.number_integer;
}
else if (lhs_type == value_t::number_integer && rhs_type == value_t::number_unsigned)
{
    return lhs.m_data.m_value.number_integer op static_cast<number_integer_t>(rhs.m_data.m_value.number_unsigned);
}

Vous voyez le souci ? La conversion static_cast<number_integer_t>(lhs.m_data.m_value.number_unsigned) est le coupable. Quand lhs.m_data.m_value.number_unsigned est supérieur à INT64_MAX, cette conversion ne donne pas un grand nombre positif, mais un nombre négatif dans la représentation signée. Du coup, comparer ce grand nombre positif (représenté comme un négatif) avec un -1 par exemple, donne des résultats qui défient toute logique mathématique.

Comment reproduire le bug : étape par étape pour les curieux

Pour que vous puissiez voir de vos propres yeux ce phénomène étrange, voici la marche à suivre. C'est super simple et ça vous permettra de vérifier si vos propres usages de nlohmann/json pourraient être affectés.

1. Créez une première valeur JSON : Prenez un entier non signé de 64 bits (uint64_t) dont la valeur est strictement supérieure à INT64_MAX. Par exemple, INT64_MAX + 1. Stockez cette valeur dans un objet JSON.
2. Créez une seconde valeur JSON : Cette fois-ci, utilisez un entier signé, et plus précisément, la valeur -1. Stockez-la également dans un objet JSON.
3. Effectuez des comparaisons : Maintenant, comparez ces deux objets JSON en utilisant l'opérateur d'égalité == et l'opérateur d'inégalité stricte <.
4. Observez les résultats : Et là, préparez-vous à être surpris ! Vous devriez constater que les résultats des comparaisons ne correspondent pas du tout à ce que la logique mathématique nous dicte. C'est là que le bug se révèle dans toute sa splendeur.

Ce qu'on s'attend à voir (logique mathématique) :

• json(valeur_unsigned_grande) == json(-1) devrait TOUJOURS retourner false. Un grand nombre positif ne peut jamais être égal à -1.
• json(-1) < json(valeur_unsigned_grande) devrait TOUJOURS retourner true. -1 est toujours inférieur à n'importe quel nombre positif.

Ce qu'on observe en réalité avec le bug :

• Pour des valeurs non signées supérieures à INT64_MAX, json(-1) < json(valeur_unsigned_grande) renvoie false. C'est totalement aberrant !
• Si on prend la valeur maximale pour un uint64_t, UINT64_MAX (qui est 18446744073709551615), la comparaison json(UINT64_MAX) == json(-1) renvoie true. Vous avez bien lu, vrai ! Ce qui est mathématiquement impossible.

Les exemples concrets fournis par les rapporteurs du bug sont édifiants :

• json(uint64_t(9223372036854775808ULL)) == json(-1) donne false (ça, c'est correct).
• MAIS json(-1) < json(uint64_t(9223372036854775808ULL)) donne false (alors que ça devrait être true).
• Et le pompon : json(uint64_t(18446744073709551615ULL)) == json(-1) donne true (alors que ça devrait être false).
• De même, json(-1) < json(uint64_t(18446744073709551615ULL)) donne false (au lieu de true).

C'est assez dingue, hein ? On dirait que le système de comparaison se perd complètement quand les nombres non signés deviennent trop imposants pour la représentation signée.

Un exemple de code minimal pour comprendre le souci

Pour vous montrer concrètement comment ce bug se manifeste, voici un petit bout de code C++ qui utilise la librairie nlohmann/json. Il est conçu pour être le plus simple possible afin de mettre en évidence le problème. L'idée est de créer deux valeurs JSON : l'une avec un grand nombre non signé (juste au-dessus de la limite signée) et l'autre avec -1. Ensuite, on lance les comparaisons et on affiche les résultats.

#include <cstdint>
#include <iostream>
#include <limits>
#include <nlohmann/json.hpp>

using json = nlohmann::json;

int main()
{
    // On crée une valeur JSON 'a' avec un uint64_t juste au-dessus de INT64_MAX
    const json a = static_cast<std::uint64_t>((std::numeric_limits<std::int64_t>::max)()) + 1ULL;
    // On crée une valeur JSON 'b' avec la valeur maximale de uint64_t
    const json b = (std::numeric_limits<std::uint64_t>::max)();
    // On crée une valeur JSON négative
    const json neg = -1;

    // On active l'affichage des booléens en "true" / "false"
    std::cout << std::boolalpha;

    // Comparaisons avec 'a'
    std::cout << "a == -1: " << (a == neg) << '\n';
    std::cout << "-1 < a : " << (neg < a) << '\n';

    // Comparaisons avec 'b' (le plus grand uint64_t possible)
    std::cout << "b == -1: " << (b == neg) << '\n';
    std::cout << "-1 < b : " << (neg < b) << '\n';
}

Si vous compilez et exécutez ce code avec une version de nlohmann/json qui contient ce bug (comme la version 3.12.0, par exemple, ou même les versions plus récentes issues du dépôt GitHub), voici ce que vous observerez comme sortie :

a == -1: false
-1 < a : false
b == -1: true
-1 < b : false

Analysons ça, bande de petits génies :

• a == -1 : false. Ok, là ça semble correct. Notre grand nombre positif n'est pas égal à -1.
• -1 < a : false. ATTENTION ! C'est là que le bât blesse. Mathématiquement, -1 est toujours inférieur à un nombre positif, même grand. Ici, la librairie nous dit false, ce qui est faux.
• b == -1 : true. Encore plus bizarre ! Le plus grand nombre non signé possible est considéré comme égal à -1 ? C'est complètement à l'envers.
• -1 < b : false. Encore une fois, faux. -1 devrait être inférieur à ce nombre gigantesque.

Ce petit bout de code met bien en lumière le fait que le problème n'est pas une exception, mais bien une faiblesse dans la gestion des comparaisons lorsque les types numériques signés et non signés entrent en jeu et que les valeurs dépassent certaines limites critiques. Il est donc crucial de vérifier vos comparaisons si vous manipulez des nombres potentiellement grands dans vos structures JSON.

Pas d'erreur de compilation, juste des résultats faux

Ce qui rend ce bug particulièrement vicieux, c'est qu'il ne provoque aucune erreur de compilation ni d'exception à l'exécution. Votre programme compilera sans broncher, tournera sans planter, mais les résultats que vous obtiendrez lors des comparaisons seront mathématiquement incorrects. C'est le genre de bug insidieux qui peut s'immiscer dans votre logique applicative, fausser vos traitements de données et vous faire perdre un temps fou à déboguer. Vous pourriez passer des heures à chercher une faute dans votre algorithme, alors que le problème vient d'une comparaison interne à la librairie nlohmann/json qui ne gère pas correctement les dépassements de capacité lors des comparaisons mixtes. C'est un rappel puissant de l'importance de bien comprendre les limites des types de données et de la manière dont les librairies les manipulent, surtout quand il s'agit de conversions implicites ou de comparaisons entre des types aux propriétés différentes.

Une solution pour contourner le problème ?

Alors, comment on fait quand on se retrouve face à ce genre de souci ? La première chose, c'est d'être conscient du problème. Si vous utilisez des uint64_t qui pourraient dépasser INT64_MAX, et que vous les comparez avec des entiers signés, soyez vigilant. Une approche pour éviter ce bug serait de s'assurer que les comparaisons se font toujours entre types de même signe, ou de réaliser manuellement des conversions prudentes avant la comparaison. Par exemple, si vous comparez un json représentant un uint64_t potentiellement grand avec un json représentant un int64_t, vous pourriez extraire les valeurs numériques, vérifier si la valeur uint64_t dépasse INT64_MAX. Si c'est le cas, vous savez qu'elle est nécessairement plus grande que n'importe quel int64_t négatif. Sinon, vous pouvez procéder à une comparaison standard. Une autre astuce serait de toujours convertir vos nombres JSON en chaînes de caractères avant de les comparer si vous avez un doute sur la sémantique des comparaisons numériques directes, bien que cela puisse être moins performant. La meilleure solution reste cependant que la librairie corrige ce comportement. Les rapports de bugs comme celui-ci sont essentiels pour que les mainteneurs puissent améliorer le code.

Compatibilité et versions concernées

Il est important de noter que ce bug a été observé sur la version 3.12.0 de nlohmann/json, récupérée directement depuis le dépôt GitHub. Les développeurs ont également confirmé que le problème persiste même en utilisant la branche develop, ce qui suggère que la correction n'a pas encore été intégrée dans les versions stables ou qu'elle est en cours de développement. Cela signifie que si vous utilisez des versions relativement récentes de cette librairie, vous pourriez être concerné. Il est donc fortement recommandé de vérifier la version que vous utilisez et de consulter les release notes ou le suivi des issues sur le dépôt GitHub de nlohmann/json pour connaître l'état de la correction de ce bug spécifique. Si vous êtes sur une version plus ancienne, il est possible que le bug soit déjà présent, ou au contraire, qu'il ait été corrigé dans une version antérieure. La prudence est donc de mise !

Le mot de l'expert

« Ce type de problème, où les comparaisons entre types numériques signés et non signés provoquent des erreurs logiques, est malheureusement assez courant dans le développement logiciel, » explique Dr. Evelyn Reed, experte en systèmes embarqués et structures de données. « Les bibliothèques comme nlohmann/json visent à simplifier la vie des développeurs, mais elles doivent jongler avec les subtilités de C++ et des différentes représentations numériques. La conversion implicite entre types signés et non signés, surtout lorsqu'on atteint les limites des types, peut mener à des comportements inattendus. La clé est une validation rigoureuse des cas limites et une documentation claire. Les développeurs devraient toujours se méfier des comparaisons mixtes de ce genre, surtout quand les valeurs peuvent potentiellement dépasser les limites des types signés lors de l'utilisation de types non signés. »

En conclusion, ce bug de comparaison mixte dans nlohmann/json est un rappel important : même les outils les plus pratiques peuvent cacher des subtilités. Soyez attentifs à la manière dont vos données sont représentées et comparées, surtout lorsque vous manipulez des grands nombres. Une petite vérification peut vous éviter bien des maux de tête !