Problème en C

Version imprimable

05/10/2007, 00h03
leffe

Problème en C

qqun pourrai-til m'aider a répondre a cette question.

Sur un machine 32 bits... il faut écrire une procédure qui fait la somme de deux nombres entiers signés sur 16 bits. Cette procédure doit permettre de détecter les cas de débordements positifs et négatifs. Cette procédure devra afficher le résultat de la somme et indiquer si le résultat correspondant est correct ou est un débordement positif ou négatif.

Merci de votre aide
05/10/2007, 10h53
Thierry Chappuis
Citation:

Envoyé par leffe

qqun pourrai-til m'aider a répondre a cette question.

Sur un machine 32 bits... il faut écrire une procédure qui fait la somme de deux nombres entiers signés sur 16 bits. Cette procédure doit permettre de détecter les cas de débordements positifs et négatifs. Cette procédure devra afficher le résultat de la somme et indiquer si le résultat correspondant est correct ou est un débordement positif ou négatif.

Merci de votre aide

Le langage C ne spécifie pas qu'un certain type d'entier doit occuper 16 bits en mémoire. Tout ce que dit la norme, c'est:
- un entier de type short doit pouvoir représenter une valeur entre -32767 et 32767
- idem pour un entier de type int
- un entier de type long doit pouvoir représenter une valeur entre -(2**31 - 1) et (2**31 - 1)
De plus la relation suivante doit être vérifiée:

Code:

sizeof(short) <= sizeof(int) <= sizeof(long)

Sur certaines architectures, les types short, int et long font tous les trois 64 bits. De plus, le langage C n'impose aucune contrainte sur la manière de représenter les entiers négatifs (complément à deux, complément à 1, bit de signe)

Pour détecter les débordements potentiels tu peux te servir des constantes symboliques SHRT_MIN, SHRT_MAX, INT_MIN, INT_MAX, etc. déclarées dans le fichier d'en-tête standard limits.h.

Thierry
05/10/2007, 11h30
nicolas.sitbon

Citation:

Envoyé par Thierry Chappuis

Le langage C ne spécifie pas qu'un certain type d'entier doit occuper 16 bits en mémoire.
Thierry

int16_t ou uint16_t en C99 et biensûr un processeur compatible.
Cordialement.
05/10/2007, 11h39
Emmanuel Delahaye

Citation:

Envoyé par leffe

qqun pourrai-til m'aider a répondre a cette question.

Sur un machine 32 bits... il faut écrire une procédure qui fait la somme de deux nombres entiers signés sur 16 bits. Cette procédure doit permettre de détecter les cas de débordements positifs et négatifs. Cette procédure devra afficher le résultat de la somme et indiquer si le résultat correspondant est correct ou est un débordement positif ou négatif.

Il faut faire un additionneur binaire. L'utilisation d'un mot de 32-bit non signé (unsigned long, par exemple) permet de gérer proprement le débordement les calculs dur 16-bit.

http://www.univ-lemans.fr/enseigneme.../addition.html

http://emmanuel-delahaye.developpez.com/bits.htm

Par contre, concernant les valeurs négatives, l'énoncé est incomplet. Il faut préciser comment sont codés les nombres négatifs. (signe+amplitude, complément à 1 ou complément à 2).
05/10/2007, 11h50
Thierry Chappuis

Citation:

Envoyé par nicolas.sitbon

int16_t ou uint16_t en C99 et biensûr un processeur compatible.
Cordialement.

Comme je n'utilise pas (ou peu, à part snprintf()) les extensions C99, j'ai tendance à les oublier...

Thierry
05/10/2007, 13h07
Emmanuel Delahaye

Citation:

Envoyé par nicolas.sitbon

int16_t ou uint16_t en C99 et biensûr un processeur compatible.

Ce qui fait que ces types, bien que standards (C99), ne sont pas portables...
05/10/2007, 16h53
nicolas.sitbon

Citation:

Envoyé par leffe

Sur un machine 32 bits...

Apparamment il ne cherche pas spécialement la portabilité. Même si ces extensions de la norme C99 ne sont pas portables, elle restent néanmoins accessibles à une majorité de machine, voilà pourquoi j'ai jugé bon de les rappeler...
05/10/2007, 17h15
Emmanuel Delahaye

Citation:

Envoyé par nicolas.sitbon

Apparamment il ne cherche pas spécialement la portabilité. Même si ces extensions de la norme C99 ne sont pas portables, elle restent néanmoins accessibles à une majorité de machine, voilà pourquoi j'ai jugé bon de les rappeler...

Justement, il y a des machines 32-bit qui n'ont pas de mots de 16-bit (DSP Freescale 56156, par exemple).
05/10/2007, 17h26
nicolas.sitbon

Oui je connais le dsp freescale, c'est l'exemple qui est toujours sorti quand on explique au gens qu'un octet ne fait pas forcément 8 bits, maintenant il faudrait voir avec l'intéressé s'il code sur dsp freescale, et si ça n'est pas le cas, voir si son compilateur implémente cette partie de la norme C99. On ne va pas se priver des extensions apportés par la norme C99 sous prétexte que le dsp freescale à l'octet qui fait 16 bits. Même si je sais que pour vous la norme C99 n'apporte pas de grandes nouveautés, il reste que pour moi, beaucoup de ces nouveauté sont incontournables mais tu fais bien de rappeler Emmanuel qu'il faut attention à la portabilité dans ce cas la même si je l'avais déjà préciser dès le début.
Cordialement.
05/10/2007, 17h44
Thierry Chappuis

Citation:

Envoyé par nicolas.sitbon

Oui je connais le dsp freescale, c'est l'exemple qui est toujours sorti quand on explique au gens qu'un octet ne fait pas forcément 8 bits, maintenant il faudrait voir avec l'intéressé s'il code sur dsp freescale, et si ça n'est pas le cas, voir si son compilateur implémente cette partie de la norme C99. On ne va pas se priver des extensions apportés par la norme C99 sous prétexte que le dsp freescale à l'octet qui fait 16 bits. Même si je sais que pour vous la norme C99 n'apporte pas de grandes nouveautés, il reste que pour moi, beaucoup de ces nouveauté sont incontournables mais tu fais bien de rappeler Emmanuel qu'il faut attention à la portabilité dans ce cas la même si je l'avais déjà préciser dès le début.
Cordialement.

A mon avis, un octet fait toujours 8 bits par définition. Par contre, la taille du byte varie avec l'architecture.

Thierry
05/10/2007, 18h57
nicolas.sitbon

Citation:

Envoyé par Thierry Chappuis

A mon avis, un octet fait toujours 8 bits par définition. Par contre, la taille du byte varie avec l'architecture.
Thierry

Non la traduction de byte en octet est un gros abus de langage qui ne date pas d'hier, c'est une erreur tout bonnement, et la norme du langage C est la pour le rappeler.
Cordialement.
05/10/2007, 19h07
Emmanuel Delahaye

Citation:

Envoyé par nicolas.sitbon

Non la traduction de byte en octet est un gros abus de langage qui ne date pas d'hier, c'est une erreur tout bonnement, et la norme du langage C est la pour le rappeler.

Comment ça non . Ce qu'a dit Thierry est parfaitement correct. C'est toi qui a parlé d'octet pouvant ne pas faire 8-bit,

Citation:

quand on explique au gens qu'un octet ne fait pas forcément 8 bits

ce qui est évidemment faux. Un octet, par définition, fait toujours 8 bit.

(Et je rappelle qu'en anglais, octet se dit octet).
05/10/2007, 19h29
nicolas.sitbon

Si on prend des dictionnaires de références comme le harrap's unabridged ou le bms, la traduction française de byte est "octet" donc c'est bien une erreur de traduction non?
05/10/2007, 19h50
Emmanuel Delahaye
Citation:

Envoyé par nicolas.sitbon

Si on prend des dictionnaires de références comme le harrap's unabridged ou le bms, la traduction française de byte est "octet" donc c'est bien une erreur de traduction non?

C'est une approximation commune en langage non technique (hors-sujet ici, on est pas des journalistes ignares mais des techniciens précis).

En langage technique, les choses sont claires :
- byte -> multiplet (plus petit mot adressable d'une architecture donnée)
- octet -> octet (mot de exactement 8-bit).
C'est tout.
05/10/2007, 20h17
nicolas.sitbon

Le bms est le dictionnaire de l'informatique, fais par des informaticiens. Je vois pas ou est le problème?
06/10/2007, 09h57
Thierry Chappuis

Citation:

Envoyé par nicolas.sitbon

Je vois pas ou est le problème?

Lorsque tu vas acheter une fondue chez le fromager (on ne renie pas ses origines), va lui expliquer que 800g signifie 1,6kg chez le concurrent d'à côté. Pour l'octet, c'est pareil: octet = 8 bits (et pas 16, etc. selon l'architecture).

Thierry

Pour en revenir au problème du PO, je propose ceci:

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
#include <stdio.h>
#include <stdlib.h>
#include <limits.h>
 
enum AddErrors {
    ADD_OK,
    ADD_ERR_ARG_OVERFLOW,
    ADD_ERR_OVERFLOW_MAX,
    ADD_ERR_OVERFLOW_MIN,
    ADD_NB
};
 
/**
 * Additionne deux valeurs codées sur 16bits et signale les débobordements.
 *
 * Si les valeurs passees en arguments ne peuvent etre representees par un
 * codage sur 16 bits, la fonction revoie 0 et err vaut ADD_ERR_ARG_OVERFLOW.
 * Si un debordement intervient, la fonction renvoie 0 et err vaut
 * ADD_ERR_OVERFLOW_MAX (debordement par le haut) ou ADD_ERR_OVERFLOW_MIN
 * (debordement par le bas).
 */
int add_16bits_numbers(int nb1, int nb2, enum AddErrors *err)
{
    /* -tc- valeur de retour */
    int rv = 0;
 
    /* -tc- teste si un entier negatif est repesente selon un complement a deux */
    int is_two_complement = (INT_MAX == - (INT_MIN + 1));
    const int MAX_SIGNED_16BITS = 32767;
    const int MIN_SIGNED_16BITS = - (MAX_SIGNED_16BITS + is_two_complement);
    enum AddErrors error = ADD_OK;
 
    /* -tc- si les valeurs passees en argument ne sont pas comprises entre
       MAX_SIGNED_16BITS et MIN_SIGNED_16BITS, la fonction renvoie 0 et une
       erreur ADD_ERR_ARG_OVERFLOW */
    if ((nb1 <= MAX_SIGNED_16BITS && nb1 >= MIN_SIGNED_16BITS) &&
            (nb1 <= MAX_SIGNED_16BITS && nb2 >= MIN_SIGNED_16BITS))
    {
        /* -tc- il ne peut y avoir debordement que si les valeurs sont les
           deux positives ou les deux negatives */
        if (nb1 > 0 && nb2 > 0 && nb1 > MAX_SIGNED_16BITS - nb2)
        {
            error = ADD_ERR_OVERFLOW_MAX;
        }
        else if (nb1 < 0 && nb2 < 0 && nb1 < MIN_SIGNED_16BITS - nb2)
        {
            error = ADD_ERR_OVERFLOW_MIN;
        }
        else /* -tc- il n'y a pas de debordement */
        {
            rv = nb1 + nb2;
        }
    }
    else
    {
        error = ADD_ERR_ARG_OVERFLOW;
    }
 
    if (err != NULL)
    {
        *err = error;
    }
 
    return rv;
}
 
int main(void)
{
    enum AddErrors err = ADD_OK;
    short nb1 = 32767;
    short nb2 = 1;
    int res;
 
    res = add_16bits_numbers(nb1, nb2, &err);
    printf("res = %d\nerr = %d\n", res, err);
 
    return 0;
}

Mon test pour déterminer si l'architecture utilise le complément à deux pour représenter les entier négatifs est douteux du point de vue de la portabilité. Ce test et la variable is_two_complement peuvent être éliminés sans faire une grande erreur sur la prédiction des débordements.

Thierry