Discussion :

[transgohan]

T'as cru que malloc alloue magiquement de la mémoire sans savoir où il va ?

Non en effet malloc fait la même chose que ce mon code fait, à savoir allouer dans un tableau statique.
Mais quand tu as besoin de compartimenter et/ou classifier la mémoire tu ne peux pas utiliser le malloc de base qui ne pointe que sur un seul espace mémoire.

Bon après cela a tout de même ses limites même si cela apporte une certaine résilience face aux développeurs qui ne codent pas les tests de dépassement mémoire (car cela ne va impacter que les données de leur module)...
J'attends toujours l'explication de l'ingénieur en chef indiquant le pourquoi un pointeur fou ne pourrait pas aller corrompre le tableau statique des données de tel module tout comme on pourrait l'avoir avec un seul grand tableau pour malloc...

[Bousk]

Tu as peut-être %hhu si ton compilateur le permet ?
Sinon, autant y aller directement avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
assert(i < 100);
chaine[0] = '0' + i / 10;
chaine[1] = '0' + i % 10;
chaine[3] = 0;

Ça peut potentiellement être plus rapide que le sprintf en plus ? 3 assignations vs appel + parsing du motif + extraction des paramètres pour remplir le motif.

[transgohan]

Merci Bousk je vais tester ce format (que je connaissais pas et que je n'avais pas trouvé avec un man).
Mais j'ai peu d'espoir vis à vis de mon compilateur si même le man de ma distrib n'affiche pas le format alors qu'elle est plus récente.

Effectivement l'affectation octet par octet est ce que je garde en dernier recours pour palier à ces défauts d'analyse.
Certes cela serait mieux niveau charge CPU mais je ne suis pas dans des portions contraintes en temps donc autant garder la lisibilité au maximum si possible.
J'ai déjà bien assez de portions de code qui nécessite une quantité non négligeable de café et de calme afin de comprendre ce que cela fait, et ce même avec les commentaires pourtant très bien fait.

[Sve@r]

Tiens ? Moi non plus je ne connaissais pas le "%hh" qui semble être venu du C++ mais qui est accepté par mon gcc.

Sinon, autant y aller directement avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
assert(i < 100);
chaine[0] = '0' + i / 10;
chaine[1] = '0' + i % 10;
chaine[3] = 0;

Ça peut potentiellement être plus rapide que le sprintf en plus ? 3 assignations vs appel + parsing du motif + extraction des paramètres pour remplir le motif.

Effectivement l'affectation octet par octet est ce que je garde en dernier recours pour palier à ces défauts d'analyse.

Surtout n'oublie pas le commentaire pour expliquer le but de l'opération. Sinon le prochain qui passe se dira "il est con lui, il ne connait pas sprintf() ?"

[transgohan]

Surtout n'oublie pas le commentaire pour expliquer le but de l'opération. Sinon le prochain qui passe se dira "il est con lui, il ne connait pas sprintf() ?"

Code c :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
// Si vous n'avez rien à faire pour les prochains 6 mois mais que vous êtes tout de même financé vous pouvez vous amuser cher développeur à remplacer le code qui suit par un sprintf.
// Et passer ainsi un temps infini à chercher une solution de correction du défaut klocwork UNBOUND_SPRINTF sur laquelle j'ai déjà passé un temps non négligeable. 
// Ou bien passer le temps requis pour rédiger au client le rapport de test ainsi que le code de mise en évidence que c'est un faux positif. 
// Ou encore vous pouvez passer votre chemin en laissant ce code tel qu'il est et aller vaquer à de meilleurs occupations. 
// signé : un développeur qui vous veut du bien

[Bktero]

on en effet malloc fait la même chose que ce mon code fait, à savoir allouer dans un tableau statique.
Mais quand tu as besoin de compartimenter et/ou classifier la mémoire tu ne peux pas utiliser le malloc de base qui ne pointe que sur un seul espace mémoire.

Ce qui est intéressant par contre, plutôt que plusieurs allocateurs de "mémoire brute", c'est d'avoir des pools de ressources : au lieu de récupérer des types, du récupère des objets Foo, Bar, Baz, etc. La gestion est simple, il n'y a pas de fragmentation.

J'attends toujours l'explication de l'ingénieur en chef indiquant le pourquoi un pointeur fou ne pourrait pas aller corrompre le tableau statique des données de tel module tout comme on pourrait l'avoir avec un seul grand tableau pour malloc...

Beaucoup de gens sont plein de conviction, et parmi eux un nombre non négligeable n'a pas de bonnes explications à ces convictions. Sans voir un peu plus en détails, difficile de juger. Mais par contre, l'allocation statique n'a jamais empêché le jardinage, c'est certain