Je soutiens du code C sur Solaris, et j'ai vu quelque chose de bizarre au moins, je pense que c'est: Ma compréhension est que puisque la variable est une matrice locale la la mémoire provient de la pile et n'a pas besoin d'être libérée, et d'ailleurs, car aucun malloc / calloc / realloc n'a été utilisé le comportement n'est indéfini. Ceci est un système en temps réel, donc je pense que c'est un gaspillage des cycles. Est-ce que je manque quelque chose d'évident?
5 Réponses :
non. Ceci est un bug.
Selon gratuitement (3) ....
libre () libère l'espace mémoire pointé à PTR, qui a dû être retourné par un appel précédent à malloc (), calloc () ou realloc (). Sinon, ou si libre (PTR) a déjà été appelé avant, non défini le comportement se produit. Si PTR est null, non l'opération est effectuée.
Vous avez donc un comportement indéfini dans votre programme.
Vous ne pouvez que libérer () quelque chose que vous avez obtenu de MALLOC (), CALLOC () ou REALLOC (). Libérez quelque chose sur la pile donnant un comportement non défini, vous avez de la chance que cela ne cale pas votre programme de planter ou de pire.
considère qu'un bug grave et supprimez cette ligne dès que possible.
"Considérons qu'un bogue grave et supprimez cette ligne dès que possible". C'est un bogue si grave que si le code actuel fonctionne correctement, je voudrais essayer de déterminer pourquoi avant de le changer. Il peut y avoir quelque chose que j'ai sérieusement mal compris (comme peut-être qu'un de ces jetons est en fait new_1ogin ou quelque chose). Je perdrais probablement mon temps, mais je serais ce paranoïaque ;-)
Peut-être que le gratuit vérifie la plage du pointeur et ne fait rien quand il s'agit d'une zone située à l'extérieur du tas. IMHO Ce n'est pas une bonne idée, mais qui sait ce que la mise en œuvre pensait (dans mon ancienne vie de programmeur intégrée, j'ai même mis en œuvre ce comportement sur l'un de nos contrôleurs d'acquisition).
D'accord, mais sur une mise en œuvre particulière, "Peut-être" devient "devient" soit comme ça, soit ça ne "pas". Je veux toujours savoir quels types de bugs sont en pratique détectables et quels types ne sont pas, car cela facilite le débogage intelligemment des problèmes futurs.
Si vous alliez mettre ce test dans votre gratuit () , vous feriez probablement quelque chose de plus à gérer que "ignorer silencieusement".
Il est possible que ce n'était pas un bug. Les crochets MALLOC peuvent définir intrinsèquement un comportement différent de la part de ce qui est défini dans la norme.
Certainement un bug. Gratuit () ne doit être utilisé que pour la mémoire du tas Alloc'd, sauf s'il est redéfini pour faire quelque chose de complètement différent, ce que je doute d'être le cas.
Dans la plupart des cas, vous ne pouvez que libérer () quelque chose attribué sur le tas. Voir http://www.opengroup.org/onlinepubs/009695399/fonctions/free .html .
Toutefois: Un moyen d'aller faire ce que vous aimeriez faire est de Scope Variables temporaires allouées sur la pile. Comme:
Le libre () est définitivement un bug.
Si la fonction ne confirmant pas pédantiquement que la connexion est de 63 caractères ou moins avec la terminaison NULL appropriée, ce code a un bug de débordement de tampon classique. Si une partie malveillante peut remplir la connexion avec les bons octets, ils peuvent écraser le pointeur de retour sur la pile et exécuter du code arbitraire. Une solution est la suivante: P>
Cependant, il est possible qu'il y a un autre bogue ici:
new_login[sizeof(new_login)-1]='\0';
strncpy(new_login, (char *)login, sizeof(new_login)-1 );
Qui a écrit ça? Ce gars devrait être
gratuit () 'd.C'est un bogue, mais il est possible que Free connaisse les limites du tas et peut repérer cela. Il est également possible que ce projet ait une bibliothèque d'allocation de tas qui fait la collecte des ordures et ne fait rien, soit une macro comme #define free (x) (x = null)
@Negoose: Si oui, ce n'est pas si macro, car
new_login = 0 ne doit pas compiler.duplicaté possible de Stackoverflow.com/Questtions/2688377/...