La conversion Mo in Go semble triviale au premier abord. Pourtant, deux systèmes de calcul coexistent, et confondre l’un avec l’autre produit des erreurs silencieuses qui passent inaperçues jusqu’au moment où elles posent problème. Cette page détaille les pièges les plus concrets, avec un focus particulier sur les erreurs que l’on commet en écrivant du code de conversion en Go.
MB ou MiB : la source de toutes les confusions de conversion
Quand vous voyez « 1 Go » sur une clé USB, le fabricant utilise le système décimal SI (base 1 000). Votre système d’exploitation, lui, raisonne souvent en base 1 024. Ce n’est pas la même chose, et l’écart grossit à chaque palier.
| Unité décimale | Valeur en octets | Unité binaire (IEC) | Valeur en octets |
|---|---|---|---|
| 1 Mo | 1 000 000 | 1 Mio (MiB) | 1 048 576 |
| 1 Go | 1 000 000 000 | 1 Gio (GiB) | 1 073 741 824 |
| 1 To | 1 000 000 000 000 | 1 Tio (TiB) | 1 099 511 627 776 |
L’écart atteint presque 10 % entre 1 To décimal et 1 Tio binaire. Dans un contexte de stockage ou de transfert de fichiers, ce pourcentage n’est pas anodin.
Vous avez déjà remarqué que votre disque dur de « 500 Go » affiche moins d’espace sous Windows ? C’est exactement cette différence de base qui l’explique. Le fabricant compte en puissances de 1 000, l’OS affiche en puissances de 1 024.
Conversion de type en Go : l’erreur que personne ne voit venir
Passons maintenant aux erreurs que l’on commet en écrivant du code de conversion en langage Go. Elles sont d’autant plus piégeuses qu’elles ne génèrent aucun message d’erreur.
Changer le type ne convertit pas l’unité
Voici une erreur très répandue chez les développeurs débutants. Supposons que vous avez une variable mo qui contient une valeur en mébioctets. Vous écrivez :
int64(mo)
Cette ligne change le type de la variable, pas sa valeur. Elle ne multiplie rien par 1 024 ou par 1 000. La spécification du langage Go distingue clairement les conversions de types et les opérations arithmétiques. Pour obtenir un nombre d’octets, il faut écrire explicitement le facteur choisi :
octets := int64(mo) * 1_048_576 (pour des mébioctets, base 1 024)
ou
octets := int64(mo) * 1_000_000 (pour des mégaoctets, base 1 000)
Choisir l’un ou l’autre sans le documenter, c’est planter une bombe à retardement dans votre code.
Tronquer un flottant sans s’en rendre compte
Deuxième piège : convertir un float64 en int64 en Go supprime la partie décimale sans arrondir. La valeur est tronquée vers zéro.
Exemple concret. Si vous avez 1,9 Go et que vous convertissez ce flottant en entier pour obtenir des octets, Go va d’abord lire « 1 », pas « 2 ». Une perte silencieuse de presque un gigaoctet peut ainsi s’accumuler dans un calcul de quota ou de bande passante.
La bonne pratique : décider explicitement de votre règle d’arrondi avant la conversion, et vérifier que la valeur reste dans la plage du type cible.
Débordement d’entier : quand multiplier devient dangereux
Vous avez déjà vu un résultat négatif pour une taille de fichier ? C’est probablement un débordement d’entier.
En Go, les calculs sur des entiers ne génèrent pas d’exception en cas de dépassement. Si vous multipliez une grande valeur par 1 000 000 000 avec un type trop petit, le résultat « boucle » silencieusement et devient faux, voire négatif.
Voici les points à vérifier avant toute multiplication :
- Vérifier la capacité du type avant la multiplication. Un
int32peut contenir au maximum environ 2,1 milliards. Une simple valeur de 3 Go en octets (3 000 000 000) dépasse déjà cette limite. - Préférer
int64ouuint64pour les tailles de fichiers. Ces types peuvent représenter des valeurs bien au-delà du pétaoctet, ce qui couvre tous les cas pratiques actuels. - Ne pas supposer qu’
intfait 64 bits. La spécification Go indique qu’intetuintfont 32 ou 64 bits selon l’architecture de la machine. Sur une plateforme 32 bits, votre calcul peut déborder là où il fonctionnait en 64 bits.
Les constantes non typées échappent à ce problème : Go les évalue avec une précision étendue et détecte le dépassement à la compilation. Mais dès que vous travaillez avec des variables à l’exécution, la responsabilité du contrôle vous revient entièrement.
Concevoir une fonction de conversion Mo/Go fiable en langage Go
Plutôt que de disperser les facteurs de conversion dans tout le code, une seule fonction bien conçue règle la plupart des problèmes décrits ci-dessus. L’objectif : travailler toujours en octets en interne, nommer explicitement la convention choisie (MB ou MiB), et signaler les cas limites.
Structure recommandée
Une telle fonction reçoit une valeur numérique et un paramètre qui précise l’unité d’entrée (« MB » pour décimal, « MiB » pour binaire). Elle retourne le résultat en octets sous forme de int64, plus une erreur si la valeur est négative ou si le résultat dépasse la plage du type.
Voici les vérifications nécessaires à intégrer :
- Rejeter les valeurs négatives dès l’entrée, car elles n’ont pas de sens pour une taille de données.
- Contrôler le dépassement avant la multiplication en comparant la valeur d’entrée au quotient de
math.MaxInt64par le facteur choisi. - Documenter le comportement d’arrondi si l’entrée est un flottant : indiquer clairement si la fonction tronque ou arrondit, et vers quelle direction.
- Retourner une erreur explicite plutôt que de laisser le calcul produire un résultat silencieusement faux.
Ce type de fonction peut sembler verbeux pour un cas simple. Mais dans un service qui gère des quotas de stockage ou des limites de téléchargement, chaque octet manquant ou en trop a un impact réel sur l’expérience utilisateur.
Récapituler les erreurs les plus fréquentes en conversion Mo/Go
Pour fixer les idées, voici les quatre confusions qui reviennent le plus souvent, que ce soit dans le code ou dans l’usage quotidien :
Confondre MB et MiB produit un écart de près de 5 % à l’échelle du mégaoctet, et presque 10 % à l’échelle du téraoctet. Sur un disque de grande capacité, cela représente une quantité substantielle de données « manquantes ».
Écrire int64(valeur) en croyant convertir une unité est l’erreur la plus fréquente en code Go. Elle ne fait que changer le type, jamais la valeur réelle.
Tronquer un flottant vers zéro sans le vouloir peut faire disparaître une fraction d’unité importante dans un calcul de quota.
Utiliser int sans vérifier l’architecture cible expose le code à un comportement différent en production selon la machine, sans aucun avertissement du compilateur.
Prendre l’habitude de nommer ses constantes (`MB`, `MiB`, `GB`, `GiB`) et de centraliser les conversions dans des fonctions dédiées est la façon la plus simple d’éviter ces quatre catégories d’erreurs à la fois.
