Tu as raison, le commentaire de la fonction devrait préciser les limitations de celle-ci. Par contre, le coup du « la fonction aura une défaillance une fois sur quatre [dans le cas général] » me semble exagéré.
Imaginons deux entiers, i1 et i2, que l'on soustrait l'un à l'autre. Posons quatre cas de figure:
i1 et i2 sont positifs: tout va bien, car dans ce cas « l'amplitude » de la soustraction tient largement dans l'intervalle [INT_MIN,INT_MAX]
i1 est négatif, et i2 est négatif : tout va bien pour les raisons exposées précédemment (i2 est complémenté à 2, et tout se passe comme d'hab').
i1 est positif, et i2 est négatif. Dans ce cas, il y a un risque d'overflow, car la somme i1 + compl2_i2 (avec compl2_i2 = -i2, positif) peut dépasser INT_MAX.
i1 est négatif, et i2 est positif. Pour les même raisons que précédemment, on peut obtenir un underflow.
Donc cette fonction est parfaitement valide pour deux int de même signe que l'on veut comparer. Si les signes peuvent être différents, il faut alors soit changer de fonction, soit avoir des garanties sur la plage de valeurs (pas forcément « petite », mais pour éviter les surprises, il faut garantir que i1 et i2 sont dans la plage [-<TYPE_ENTIER>_MAX/2,<TYPE_ENTIER>_MAX/2].
Certains pourront arguer que prendre un type entier (short,int,long, etc.) et diviser la plage de valeurs par deux n'est pas très malin. Je trouve que c'est discutable, et que ça dépend fortement de la plate-forme visée. Dans le cas d'un code à destination de l'embarqué, chaque octet compte, donc il faut bien faire attention. Dans le cas d'une machine type PC, les données stockées sur le disque prennent bien plus de place que le code (c'est d'ailleurs pour ça que le format Mach-O d'OS X avait été adopté : lorsqu'on a un programme avec 500Mio de données, doubler la taille du binaire pour pouvoir tourner sur PPC et x86 n'est pas un grand prix à payer). En pratique sur une machine 64 bits et conforme à POSIX, sizeof(long) = sizeof(void*) et est la taille d'un registre. Donc du point de vue purement lié à l'efficacité (et pas au stockage en mémoire), que j'utilise un int ou un long ne change rien, tout se passera de la même façon.
[^] # Re: Ca traduit bien un état d'esprit de la part des développeurs de systemd
Posté par lasher . En réponse au journal Systemd vs Linux, quand l'intransigeance d'un développeur tourne au ridicule.... Évalué à 2.
Tu as raison, le commentaire de la fonction devrait préciser les limitations de celle-ci. Par contre, le coup du « la fonction aura une défaillance une fois sur quatre [dans le cas général] » me semble exagéré.
Imaginons deux entiers,
i1eti2, que l'on soustrait l'un à l'autre. Posons quatre cas de figure:i1eti2sont positifs: tout va bien, car dans ce cas « l'amplitude » de la soustraction tient largement dans l'intervalle[INT_MIN,INT_MAX]i1est négatif, eti2est négatif : tout va bien pour les raisons exposées précédemment (i2est complémenté à 2, et tout se passe comme d'hab').i1est positif, eti2est négatif. Dans ce cas, il y a un risque d'overflow, car la sommei1 + compl2_i2(aveccompl2_i2 = -i2, positif) peut dépasserINT_MAX.i1est négatif, eti2est positif. Pour les même raisons que précédemment, on peut obtenir un underflow.Donc cette fonction est parfaitement valide pour deux
intde même signe que l'on veut comparer. Si les signes peuvent être différents, il faut alors soit changer de fonction, soit avoir des garanties sur la plage de valeurs (pas forcément « petite », mais pour éviter les surprises, il faut garantir quei1eti2sont dans la plage [-<TYPE_ENTIER>_MAX/2,<TYPE_ENTIER>_MAX/2].Certains pourront arguer que prendre un type entier (
short,int,long, etc.) et diviser la plage de valeurs par deux n'est pas très malin. Je trouve que c'est discutable, et que ça dépend fortement de la plate-forme visée. Dans le cas d'un code à destination de l'embarqué, chaque octet compte, donc il faut bien faire attention. Dans le cas d'une machine type PC, les données stockées sur le disque prennent bien plus de place que le code (c'est d'ailleurs pour ça que le format Mach-O d'OS X avait été adopté : lorsqu'on a un programme avec 500Mio de données, doubler la taille du binaire pour pouvoir tourner sur PPC et x86 n'est pas un grand prix à payer). En pratique sur une machine 64 bits et conforme à POSIX,sizeof(long) = sizeof(void*)et est la taille d'un registre. Donc du point de vue purement lié à l'efficacité (et pas au stockage en mémoire), que j'utilise unintou unlongne change rien, tout se passera de la même façon.