Stlink: Code propre avec un type de variable unifié

Créé le 6 avr. 2020 · 6Commentaires · Source: stlink-org/stlink

Autant que je sache, de nombreuses fonctions utilisent des variables de longueur fixe. Il est en effet utile pour les fonctions qui doivent gérer un format de données fixe. Cependant, l'abus de variables de longueur fixe provoque des échecs de construction potentiels et des conversions non essentielles.

Par exemple dans src/usb.c :

send_recv accepte txsize et rxsize comme size_t mais dans le contexte réel, ces arguments doivent être convertis en int ou unsigned int , sans une longueur fixe, et celui qui l'appelle fournit des arguments d'un type différent( uint32_t ou des nombres magiques dans ce cas). une conversion non intentionnelle de 32 bits à 64 bits est appliquée au processus appelant. De plus, pour éviter un échec de génération, de nombreux transtypages explicites sont nécessaires.

Je suggère de remplacer les variables de longueur fixe en fonction de leurs utilisations réelles.
Rester flou pour être plus portable.

J'aimerais essayer si d'autres le trouvent significatif.

codfeedback codrefactoring needissuer-feedback

Source

chenguokai

👍1

Tous les 6 commentaires

Merci d'avoir mis cela à l'ordre du jour. Comme il s'agit d'un problème général dans toute la base de code, je ne suis pas sûr pour le moment si nous devrions le mettre immédiatement dans la v1.6.1. @martonmiklos a précédemment demandé de faire un nettoyage lié au style de code, que j'ai poussé dans le jalon v1.6.2. Ce serait peut-être aussi un bon endroit pour ce problème, même si cela le poussera un peu plus loin.

Nightwalker-87 le 6 avr. 2020

Peut-être que je peux faire un peu de nettoyage localement et suivre le processus de développement.😃

chenguokai le 6 avr. 2020

Bien sûr, vous le pouvez, mais assurez-vous de vous éloigner de develop et de continuer à suivre cette branche, au lieu de master , qui n'est plus utilisé pour les changements fréquents, mais uniquement pour les versions et les correctifs.

Nightwalker-87 le 6 avr. 2020

👍1

En ce qui concerne la compatibilité entre ILP32, LLP64 et LP64, je pense que ce serait une bonne idée de remplacer le type de données long par int32_t , mais si l'on veut exclure les surprises à l'avenir liées à conversion, nous pouvons envisager de passer à des types entiers à largeur fixe dans la mesure du possible...

Nightwalker-87 le 9 mai 2020

👍1

@chenguokai : je vous laisse ça. Vous pouvez contribuer, si vous le souhaitez et si vous avez un peu de temps.

Nightwalker-87 le 3 juin 2020

Bien sûr que je le ferai, avant la sortie. Je suis occupé maintenant.😔

chenguokai le 7 juin 2020

👍1

Cette page vous a été utile?

0 / 5 - 0 notes