markand a écrit:

Notez toutefois que même si un tableau peut être converti en pointeur ça reste des déclarations différentes. Une fonction qui prend un tableau a besoin de connaitre la définition de l'objet et ça c'est pas pratique.

struct unknown;

void f(struct unknown tab[]) {} // FAIL.
void g(struct unknown *ptr) {}  // OK.

Alors j'ai cherché l'explication dans la norme etoussa …

En fait c'est bien plus simple qu'il n'y paraît. C'est le fait de déclarer un tableau dont le type des éléments est incomplet qui est interdit par la norme (6.7.6.2 Array Declarators), règle qui prend le pas sur les histoire d'ajustement de tableaux en pointeurs. Au premier alinéa dans la partie décrivant les contraintes  on trouve «The element type shall not be an incomplete or function type.».

Et voilà le pourquoi du comment …

Edit: Du coup msvc et icc ne sont pas conformes  moins sur ce point. Le point revient à gcc et clang

-
Edité par White Crow 28 décembre 2021 à 22:19:16

robun a écrit:

C'est vrai qu'on ne sait toujours pas pourquoi 'strcpy' ne marche plus. A-t-il été réparé ? Dans le doute, je préfère ne plus l'utiliser !

Bonjour !

Et bien en effet, il n'a pas tort quand il dit "strcpy ne marche plus", et je vais expliquer pourquoi

Comme vous le constatez, si je compile ce code directement, Visual C++ 2019 m'envoie une erreur. Refus catégorique.

Mais il me dit "si quand même tu veux que ça marche, définis _CRT_SECURE_NO_WARNINGS". Donc ici je l'ai mis en haut du code (commenté), si je le décommente, tout marche.

Et si on veut compiler un vieux projet, il suffit de rajouter _CRT_SECURE_NO_WARNINGS dans le proprocesseur pour compiler.

Maintenant, pourquoi ont ils fait ça ?

-> Et bien strcpy, tout comme sprinf, strcat, etc etc.... sont des passoires à sécurité. Des fonctions qui peuvent déborder sans contrôle, et des cibles parfaites pour tout ce qui est attaque par buffer overflow.

En un mot, ce sont de vieilles fonctions de merde 

Voila pourquoi Visual C++ a choisi de bannir ces fonctions (en gardant une possibilité de les garder tout de même), et propose des fonctions sécurisées à la place, par exemple strcpy_s qui demande un paramètre supplémentaire : la taille du buffer dest.

(après, c'est pas forcément malin non plus car strcpy_s n'est pas vraiment portable, me semble t il, et ça pose d'autres soucis)

Au boulot, nos clients veulent des codes "secure", c'est le mot à la mode. De plus en plus de clients exigent cela. 

Donc finalement, il faut maintenant éviter d'utiliser ces anciennes fonctions. 

Microsoft a fait un choix violent de remonter cela en erreur (ça faisait cependant beaucoup de versions de Visual ou ça remontait en warning, mais la ils sont passés au dessus), même s'il existe un moyen simple d'ignorer et de faire marcher les anciens codes tout de même.

Disons que les fonctions *_s sont définies depuis C11 dans l'annexe K. strcpy_s en fait partie ⇒ K.3.7.1.3

 C'est une annexe normative optionnelle. C'est dnoc au moins un deuxième point sur lequel msvc n'est pas conforme.

Oui, c'est bien ce qui me semblait, les *_s au niveau portabilité c'est loin d'être parfait.

Au boulot, on les évite aussi, on s'est reprogrammé ce dont on avait besoin .... (mais safe. On n'a pas reprogramme strcpy, mais plutôt un clone de strcpy_s)

-
Edité par Fvirtman 28 décembre 2021 à 22:29:57

Merci Fvirtman, je comprends mieux ! « Ne marche plus », c'était dans le sens « n'est plus supportée » et non pas « ne fonctionne plus », ce qui m'a trompé.

robun a écrit:

Merci Fvirtman, je comprends mieux ! « Ne marche plus », c'était dans le sens « n'est plus supportée » et non pas « ne fonctionne plus », ce qui m'a trompé.

Disons que quand quelqu'un dit "ça ne marche pas", ça veut tout dire et rien dire On ne sait jamais si effectivement il y a un soucis avec la fonction, ou alors si l'auteur ne sait pas l'utiliser comme il faut

(et c'est souvent le 2e cas ! )

Mais la.... exceptionnellement c'était le premier !

Pour être plus direct avec vous, les fonctions _s ont été proposées par microsoft et ... personne d'autre que microsoft les a implémenté. De toute façon à partir du moment où quelque chose est optionnel dans la norme, qui va vraiment vouloir les implémenter ? 🙂

Que microsoft mettent des warnings parce qu'on utilise strcpy c'est pas le code le problème, c'est le compilateur. strcpy est une fonction dangereuse certes mais elle reste utilisable quand on sait ce qu'on fait (exemple : copier une chaine fixe ne venant pas de l'utilisateur).

markand a écrit:

Pour être plus direct avec vous, les fonctions _s ont été proposées par microsoft et ... personne d'autre que microsoft les a implémenté. De toute façon à partir du moment où quelque chose est optionnel dans la norme, qui va vraiment vouloir les implémenter ? 🙂

Ceux qui veulent piquer des clients à MicroSoft en fournissant des produits compatibles.

L'extension de la norme est une stratégie vieille comme l'informatique. On part d'une norme qui est censée garantir une compatibilité, on lui rajoute des extensions, et les clients qui utilisent les extensions qui "améliorent" se retrouvent avec des sources incompatibles => ils sont coincés chez leur fournisseur.

Exemple typique : le HTML amélioré par Microsoft, qui ne s'affichait correctement qu'avec son navigateur.

https://fr.wikipedia.org/wiki/Embrace,_extend_and_extinguish

-
Edité par michelbillaud 29 décembre 2021 à 12:23:26