strdupa(3) n'existe pas sous *BSD mais en C99 c'est un peu inutile puisqu'on peut utiliser des tableaux de taille inconnue à la compilation sur la pile (il fait l'alloca(3) tout seul).
Les tableaux de longueur variable (ou variable-length arrays, VLA) sont en effet une nouvelle fonctionnalité du C99, mais il faut noter que le support de GCC pour cette fonction est broken, dixit http://gcc.gnu.org/gcc-4.1/c99status.html . A utiliser avec prudence, donc...
[^] # Re: meuh
Posté par alf . En réponse au journal Shake : secouez vos fichiers, c'est pour leur bien !. Évalué à 2.
Les tableaux de longueur variable (ou variable-length arrays, VLA) sont en effet une nouvelle fonctionnalité du C99, mais il faut noter que le support de GCC pour cette fonction est broken, dixit http://gcc.gnu.org/gcc-4.1/c99status.html . A utiliser avec prudence, donc...
Si l'implémentation de malloc() est telle que les perf sont mauvaises, pourquoi ne pas utiliser un gestionnaire de mémoire intermédiaire ? La glibc implémente "obstacks" ( http://www.gnu.org/software/libc/manual/html_node/Obstacks.h(...) ). Une recherche rapide ("memory pool C") me donne aussi http://www-128.ibm.com/developerworks/linux/library/l-memory(...) qui donne plein de liens, dont la bibliothèque Apache http://apr.apache.org/docs/apr/group__apr__pools.html . Ca serait sûrement beaucoup plus portable que alloca ou strdupa().