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