Diff�rence de taille d'ex�cutable

Bonjour � tous,

J'ai un probl�me de taille d�ex�cutable lorsque j'utilise une librairie qui traite les cha�nes de caract�res utf8 en C. La librairie est disponible sur github � l�adresse suivante : https://github.com/sheredom/utf8.h

Ce que je ne comprends pas c'est pourquoi si je place tous les sources (fichier *.h et *.c) dans le m�me r�pertoire l'ex�cutable final fait 35.6 Ko alors que si je place les fichiers *.h dans un r�pertoire "include" et les fichiers *.c dans un r�pertoire "source" l'ex�cutable final 82.8 Ko. Ce n'est pas �norme comme diff�rence mais sur un plus gros programme qui utilise ces m�mes librairies la diff�rence de taille est de 122.4 Ko vs 528.3 Ko.

Dans les deux cas j'utilise le compilateur gcc qui est livr� avec Debian 12. Dans les deux cas la compilation est faite via des Makefile.

J'ai joint une petite archive de d�monstration, si quelqu'un est en mesure d'expliquer ce qui se passe j'appr�cierais.

Merci � l'avance.

P.S. J'ai une mani�re d'�crire le code C qui n'est pas orthodoxe, ceci �tant mentionn� le compilateur ne se plaint pas du tout alors je consid�re le code comme �tant valide.

Bonjour,

Dans un Makefile, les donn�es de debug sont demand�es (option -g), pas dans l'autre!

Bonjour

Citation:

---

Envoy� par StarBootics

J'ai une mani�re d'�crire le code C qui n'est pas orthodoxe, ceci �tant mentionn� le compilateur ne se plaint pas du tout alors je consid�re le code comme �tant valide.

---

Au-moins tu es en coh�rence avec toi-m�me (par rapport � tous ceux qui �crivent du C en consid�rant leur code comme non-valide je veux dire)...

Ceci dit le compilateur ne fait que v�rifier la syntaxe et la coh�rence des types, il ne dit rien sur les "bonnes pratiques". Tu peux par exemple diviser par "i" avec "i" valant 0, il compilera sans souci.
Ainsi

• au lieu de g�rer les erreurs tu sors en exit() si un truc se passe mal (ligne 36, 114, 138, 503). Et tant pis pour tout ce qui a �t� fait en amont. Accessoirement le "else" de la ligne 144 est tout aussi valide qu'il est inutile
• comme g�rer les erreurs est devenu en fait trop chiant, finalement tu ne les g�res plus du tout et tu fais de l'allocation non v�rifi�e (lignes 186, 205, 226, 246, 267, 276, 290, 337, 366, 388, 399 (ici tu avais strdup() qui fait le job), 414, 422)
• les codes de traitement du cas if (This->FreeBuffer == false) en ligne 224 (qui d'ailleurs aurait pu �tre plut�t �crit if (This->FreeBuffer != true) ou m�me if (! This->FreeBuffer) pour suivre les recommandations en mati�re d'�valuation de bool�ens) sont totalement identiques. L'un travaille � partir de TemporaryBuffer et l'autre de This->Buffer. Un peu de factorisation de code n'aurait pas �t� inutile. Mais sinon oui, c'est valide.
• ta m�thode pour convertir un float en string (fonction EasyString_StrF() en ligne 409) est effectivement peu orthodoxe. En effet, tu commences par compter la taille du float en utilisant snprintf() avec une taille � 0. Or c'est justement un cas particulier o� les normes ne sont pas d'accord sur la valeur retourn�e
  
  Citation:

  ---

  En ce qui concerne la valeur de retour de snprintf(), SUSv2 et C99 sont en contradiction : lorsque snprintf() est appel�e avec un argument size=0 SUSv2 pr�cise une valeur de retour ind�termin�e, inf�rieure � 1...

  ---

  => http://www.man-linux-magique.net/man3/sprintf.html. Si encore il n'y avait pas eu d'autre solution bon on aurait pu se dire "tant pis on est oblig�" mais voil�, il y en a d'autres qui ne posent pas de souci (commencer par copier la chaine dans une zone tampon de taille pr�sum�e suffisante comme 256 puis strdup() qui se charge d'allouer ce qui faut et copier). Et �a s'applique aussi � la m�thode EasyString_StrD() qui convertit un double en string � la ligne 419. D'ailleurs pour �a peut-�tre qu'une seule fonction commune � laquelle on aurait donn� une indication "float/double" aurait pu s'envisager mais en fait m�me pas. Puisque printf() et ses soeurs savent diff�rencier un float d'un double, en r�alit� une simple fonction unique aurait suffit...

Bon ben voil� ce qu'on peut dire en premi�re lecture de ce "code valide"...

Bonjour � tous,

C'est certain que la commande -g ajoute les symboles de d�bogage dans l'ex�cutable et donc il sera plus gros. :oops:

Pour �tre honn�te, j'ai fait aucune programmation en langage C au cours des derni�res 20 ann�es. Pendant la p�riode en question j'ai fais de la programmation avec PureBasic. Alors travailler avec les fichiers make, programmer en langage C et param�trer le compilateur c'est un peu nouveau.

De plus, je viens de me rendre compte que l'archive que j'ai t�l�vers�e ne contient pas la version la plus r�cente de ma librairie EasyString.

Merci � tous.
StarBootics