Discussion :

[homeostasie]

Bonjour,


J'ai récemment été confronté à un plantage d'une application embarquée suite à un appel à la fonction sscanf(). A savoir que précédemment, avant que j'intervienne sur ce bug, il n'y a jamais eu de soucis concernant ce code. Il est possible qu'entre-temps des options de compilation ou de version de libc aient été modifiées.

Bref, voici l'allure du code incriminé:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
int SSCANF(char *buffer, unsigned long *value_pu4)
{
    if (sscanf(buffer, "%d", value_pu4) != 1)
        return 0;
 
    return 1;
}
 
int main()
{
    char *buffer = "1 2";
 
    //unsigned long value; // <= Ici, çà ne plante pas, heureusement.
    char value;               // <= Ici, çà plante!
    SSCANF(buffer, &value);
 
    return 0;
}

J'aimerais savoir si quelqu'un a des informations ou une explication sur le fonctionnement interne de pourquoi le passage d'une variable ne correspondant pas au type sur lequel le pointeur est censé pointé peut provoquer un plantage?
Problème d'alignement? Un type d'overflow?

Merci.

[Médinoc]

Les risques: Corruptions de données, segfault en tentant d'écrire sur une zone mémoire à lecture seule...

Dans le cas présent, tu peux avoir des problèmes d'alignement, et selon l'architecture, ton char contiendra soit l'octet faible, soit l'octet fort de l'entier saisi.

[diogene]

Il n'y a tout simplement pas assez de place pour stocker la donnée :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

if (sscanf(buffer, "%d", value_pu4) != 1)....

impose que value_pu4 soit l'adresse d'une zone mémoire allouée pour stocker un int. Comme tu passes l'adresse d'une zone mémoire allouée d'un byte, sscanf va écrire à l'extérieur de la zone allouée -> plantage.

[homeostasie]

Hum oui, c'est bien ce que je me doutais.
Comme vous dîtes, le plantage est probablement dû à une "segmentation fault", provoqué par l'écriture de 3 octets indésirable pour une plateforme 32 bits. Souvent ça parait anodin, car on corrompt la variable directement situé à l'adresse au-dessus dans la pile et selon comment on utilise celle-ci, on ne modifiera pas le contexte mais dans d'autre cas, boum!

Ce qui me surprends tout de même, c'est que le code a la forme suivante:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
static void write_data (unsigned char *commande)
{
    char buffer[5];
    char value = 0;
 
    memset(buffer, 0, sizeof(buffer));
    SSCANF(&commande[2], &value);
    ...
}

Pour moi, il n'y aurait pas du avoir plantage mais corruption du contenu de "buffer" et risque de mauvaise valeur dans "value" selon l'endianness.

En tout cas, merci pour vos réponses qui clarifient bien les risques!

[diogene]

Pour moi, il n'y aurait pas du avoir plantage mais corruption du contenu de "buffer" et risque de mauvaise valeur dans "value" selon l'endianness.

Nulle part, il n'est dit dans quel ordre seront empilées les variables locales et notamment pas si cela est lié à l'ordre de leur définition dans le code.

[homeostasie]

Nulle part, il n'est dit dans quel ordre seront empilées les variables locales et notamment pas si cela est lié à l'ordre de leur définition dans le code.

D'accord, je note.