Discussion :

[olivier_u]

Bonjour,

J'ai pour mission de passer Cpptest (de Parasoft) sur un code (que je n'ai pas �crit) afin de v�rifier sa compatibilit� avec un certain nombre de r�gles MISRA.
Alors, soit le module Cpptest n'est pas au moins, soit un truc m'�chappe mais j'ai l'impression de tourner en rond.

J'utilise une fonction qsort personnalis�e � laquelle je ne peux toucher (et il n'est pas question de ne pas appeler cette fonction). Cette fonction a pour prototype :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
void mon_qsort (void *tableau,
                size_t nb_elem,
                size_t taille_elem,
                mon_int (*compare) (const void *, const void *));

Je l'utilise de la mani�re suivante :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
mon_qsort((void *)mon_tableau,
          (size_t) nombre_elements,
          (size_t) taille_elem,
          (mon_int (*) (const void *, const void *))ma_comparaison);

Le code de la fonction ma_comparaison est le suivant :

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
19
mon_int ma_comparaison(const ma_structure * const i_pa, const ma_structure * const i_pb)
{
  mon_int resultat;
 
  if (i_pa->valeur > i_pb->valeur)
  {
    resultat = -1;
  }
  else  if (i_pa->valeur < i_pb->valeur)
  {
    resultat = 1;
  }
  else
  {
    resultat = 0;
  } 
 
  return resultat;
}

Quand je passe Cpptest, j'ai une erreur MISRA sur le qsort, en particulier pour la quatri�me entr�e :
"MISRA2008-5_2_6 : Do not convert a pointer to function 'ma_comparaison' to any other pointer type".

Qu'� cela ne tienne, je d�cide de faire quelques petits changement. L'appel � mon_qsort devient :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
mon_qsort (void *)mon_tableau,
          (size_t) nombre_elements,
          (size_t) taille_elem,
           ma_comparaison);

et ma fonction de comparaison est modifi�e de la fa�on suivante. Si je n'ai plus d'erreur MISRA sur le qsort, j'en ai dans mon code maintenant (que je mets en commentaires) :

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
19
20
21
mon_int ma_comparaison(const void * const i_pa, const void * const i_pb)
{
  mon_int resultat;
  const ma_structure * const pa = static_cast<const ma_structure *>(i_pa); //MISRA2008-5_2_8 : do not convert pointer to void type to an object pointer type 'const mon_namespace::ma_structure *'
  const ma_structure * const pb = static_cast<const ma_structure *>(i_pb); //MISRA2008-5_2_8 : do not convert pointer to void type to an object pointer type 'const mon_namespace::ma_structure *'
 
  if (pa->valeur > pb->valeur)
  {
    resultat = -1;
  }
  else  if (pa->valeur < pb->valeur)
  {
    resultat = 1;
  }
  else
  {
    resultat = 0;
  } 
 
  return resultat;
}

Pas sp�cialement convaincu, je change les static_cast en dynamic_cast.
Mes erreurs MISRA disparaissent pour laisser place � d'autres... absolument incompr�hensibles � mes yeux :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
mon_int ma_comparaison(const void * const i_pa, // MISRA2008-0_1_11 : Parameter 'i_pa' is not used.
                       const void * const i_pb) // MISRA2008-0_1_11 : Parameter 'i_pb' is not used.
{
  mon_int resultat;
  const ma_structure * const pa = dynamic_cast<const ma_structure *>(i_pa); //MISRA2008-01_3_a : Local variable 'pa' declared but not used
                                                                            //MISRA2008-01_3_b : Local variable 'pa' declared but not used
  const ma_structure * const pb = dynamic_cast<const ma_structure *>(i_pb); //MISRA2008-01_3_a : Local variable 'pb' declared but not used
                                                                            //MISRA2008-01_3_b : Local variable 'pb' declared but not used
 
  [...]
}

Comment peut-il dire que les param�tres et variables ne sont pas utilis�s ???
Cpptest est-il fiable, comme outil.

Y a-t-il un moyen de faire autrement en gardant l'esprit du code ?

Merci d'avance pour votre aide.

[Luc Hermitte]

Vois avec tes sup�rieurs et tes clients si le respect de cette r�gle est plus important que l'utilisation de la fonction.

PS: std::sort, c'est bien pourtant! (et c'est certainement plus rapide...)
PPS: dynamic_cast n'a aucun rapport avec ce que tu cherches � faire. Le seul cast valide ici est un static_cast. Sauf que MISRA t'interdit ces manipulations vu que le C++ offre un typage plus fort que le C gr�ce aux templates. Tu vas te faire bananer sur toutes les conversions de pointeurs par MISRA C++. Donc soit ton client veut absolument la conformit� � MISRA C++, plus de perfs, et plus de stabilit� et tu pars sur std::sort, soit vous r�ussissez � lui vendre une fonction h�rit�e du C dans un contexte C++ et vous obtenez une d�rogation du client.

[olivier_u]

Vois avec tes sup�rieurs et tes clients si le respect de cette r�gle est plus important que l'utilisation de la fonction.

Dans la mesure o� la fonction est une fonction valid�e d�j� pr�te � utilisation car port�e sur cible, on ne va pas en changer (j'aurais peut-�tre d� pr�ciser que c'�tait destin� � �tre port� en temps r�el).

PPS: dynamic_cast n'a aucun rapport avec ce que tu cherches � faire. Le seul cast valide ici est un static_cast.

D'accord, mais pourquoi ? J'avoue que j'ai un peu du mal � saisir la nuance. Le static_cast, si j'ai bien compris, v�rifie que c'est valable � la compilation alors que le dynamic_cast le fait � l'ex�cution, mais si tu pouvais m'expliquer pourquoi le static_cast est le SEUL valable, je crois que je me coucherai moins b�te ce soir.

Sauf que MISRA t'interdit ces manipulations vu que le C++ offre un typage plus fort que le C gr�ce aux templates.

C'est un code h�rit� d'un code C. C'est un peu b�tard, je le con�ois.
MISRA n'aurait pas r�l� si j'avais fait un cast classique (monpointeur *) si c'�tait du C pur ?

Merci pour les r�ponses, en attendant.

[Luc Hermitte]

Dans la mesure o� la fonction est une fonction valid�e d�j� pr�te � utilisation car port�e sur cible, on ne va pas en changer (j'aurais peut-�tre d� pr�ciser que c'�tait destin� � �tre port� en temps r�el).

Je comprends le c�t� valid�. Pour le c�t� temps-r�el, une fois de plus, std::sort a des chances non n�gligeables d'�tre plus rapide, mais elle risque d'impliquer un embonpoint sup�rieur du binaire si la fonction de tri �tait employ�e avec plusieurs types de tableaux.

si tu pouvais m'expliquer pourquoi le static_cast est le SEUL valable, je crois que je me coucherai moins b�te ce soir.

Pour comprendre les divers casts: https://www.developpez.net/forums/d9...p/#post5210670

C'est un code h�rit� d'un code C. C'est un peu b�tard, je le con�ois.
MISRA n'aurait pas r�l� si j'avais fait un cast classique (monpointeur *) si c'�tait du C pur ?

Les r�gles qui coincent sont des r�gles de MISRA-C++ parce que l'on sait peut �crire du code plus robuste en C++ gr�ce aux templates. Donc effectivement, si tu n'appliques que MISRA-C, parce que le code serait alors uniquement en C, il n'y aura pas de probl�me.


Mais je le rappelle, la bonne d�marche n'est pas de triturer le code pour que �a passe comme par magie sans que l'on ne sache pourquoi (le but des r�gles MISRA est aussi de combattre la magie des �toiles). C'est de se dire � un moment donn� : c'est comme �a que l'on veut proc�der et on veut, main dans la main avec le client, qu'il valide notre choix avec une d�rogation qu'il nous conc�dera officiellement. Un client peut tout � fait comprendre la notion de faux positif. Si vous �tes sur de l'embarqu� o� le C est une tradition, il acceptera. Et surtout s'il vous a fait signer l'utilisation de MISRA-C++, c'est le seul qui puisse d�coincer la situation: soit la conformit� � un ensemble de r�gles, soit l'utilisation d'une fonction estampill�e OK par XXX.

[dragonjoker59]

Les m�mes r�gles existent en MISRA C, il y a cette r�gle:

Rule 11.5

A conversion should not be performed from pointer to void into pointer to object

Que tu auras donc si tu tu utilises la norme MISRA C, et la m�me r�gle pour la conversion de fonction:

Rule 11.1

Conversions shall not be performed between a pointer to a function and any other type

La seule conversion de pointeur autoris�e si je ne me trompe est la conversion vers void *

[olivier_u]

La seule conversion de pointeur autoris�e si je ne me trompe est la conversion vers void *

En fait, j'ai fini par comprendre que quand on a un void *, MISRA ne veut pas qu'on le transtype explicitement.
Par exemple, avec calloc ou malloc, il faut faire

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

int * p = malloc(n * sizeof(int));

et non pas

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

int * p = (int *)malloc(n * sizeof(int));

L�, j'avoue, je tombe un peu des nues, �a va � l'encontre de tout ce qu'on m'a appris ("point de transtypage implicite ne feras").

[olivier_u]

Pour comprendre les divers casts: https://www.developpez.net/forums/d9...p/#post5210670

Merci pour le lien.

Les r�gles qui coincent sont des r�gles de MISRA-C++ parce que l'on sait peut �crire du code plus robuste en C++ gr�ce aux templates. Donc effectivement, si tu n'appliques que MISRA-C, parce que le code serait alors uniquement en C, il n'y aura pas de probl�me.

Encore que...

Mais je le rappelle, la bonne d�marche n'est pas de triturer le code pour que �a passe comme par magie sans que l'on ne sache pourquoi (le but des r�gles MISRA est aussi de combattre la magie des �toiles). C'est de se dire � un moment donn� : c'est comme �a que l'on veut proc�der et on veut, main dans la main avec le client, qu'il valide notre choix avec une d�rogation qu'il nous conc�dera officiellement. Un client peut tout � fait comprendre la notion de faux positif. Si vous �tes sur de l'embarqu� o� le C est une tradition, il acceptera. Et surtout s'il vous a fait signer l'utilisation de MISRA-C++, c'est le seul qui puisse d�coincer la situation: soit la conformit� � un ensemble de r�gles, soit l'utilisation d'une fonction estampill�e OK par XXX.

C'est un peu plus compliqu� que �a : je suis parachut� sur un code que je n'ai pas �crit pour faire passer MISRA dessus et montrer qu'il est grosso modo MISRA-compatible. Par contre, il n'est plus temps de tout r��crire de z�ro. Donc on corrige ce qui � l'�vidence � �t� �crit parfois de mani�re un peu l�g�re pour renforcer les v�rifications de s�curit� mais on ne repart pas � z�ro. Quant au client, je ne suis m�me pas s�r qu'il comprenne beaucoup d�s lors qu'on rentre dans les d�tails.

N�anmoins, au-del� de ces probl�mes, je souhaitais savoir si certains avaient d�j� eu affaire � CppTest. Parce que dans ma bo�te, �a semble �tre une religion... Mais quand je vois CppTest me conseiller de passer une variable affect�e � droite et � gauche en const ou qu'il me dit qu'un param�tre n'est pas utilis� contre toute �vidence, j'avoue que la confiance que j'ai dans cet outil en prend un s�rieux coup.

Merci quand m�me pour les r�ponses.

[Luc Hermitte]

cpptest comme beaucoup d'autres outils pre-clang n'ont pas une compr�hension parfaite du code source. Il est donc classique d'assister � des mauvaises interpr�tations.
Ici, en revanche, la faute n'est pas du fait de l'outil.
(Quand je dis pr�-clang, c'est � cause de ce genre de choses que l'on doit � clang: https://github.com/rettichschnidi/clang-tidy-misra -- pas test�, je ne sais donc pas ce qu'il vaut pour passer les r�gles MISRA)

Pour les deux exemples � coup de malloc. Le premier est du C valide, mais ne compilera pas en C++. Ici, la solution serait new[], ou mieux, un type tel que std::vector<>, voire dynarray (boost ou c++17?) si on n'a pas besoin de redimensionner dynamiquement le tableau.