Discussion :

[cirdan_elf]

1) Pourquoi les fonctions vprintf prennent-elles en paramètre un argument de type va_list au lieu de va_list * ?

1bis) Est-ce que ça aurait pu marcher aussi avec un argument de type va_list * ? (voir ci-dessous)

2) Quand on travaille dans un environnement où on ne peut pas utiliser d'allocation dynamique est-ce qu'il est dangereux d'utiliser ces fonctions/macros (va_start etc...) ? (est-ce que par exemple elles vont faire des malloc() ?)

Merci.


* Par exemple dans le K&R, il y a un exemple du genre :

Code :

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

1
2
3
4
5
6
7
8
9
10
void erreur(const char *format, ...)
{
    va_list args;
 
    va_start(args, format);
 
    vprintf(format, args);
 
    va_end(args);
}

s'aurait pu être :

Code :

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

1
2
3
4
5
6
7
8
9
10
void erreur(const char *format, ...)
{
    va_list args;
 
    va_start(args, format);
 
    vprintf(format, &args);
 
    va_end(args);
}

si vprintf() prenait un pointeur non ?

[Jenna]

si tu regardes la déclaration de va_list dans les include file, il y a de forte chance que cela soit déjà un pointeur.

Sur mon environnement de dev (Visual Studio 2005), c'est un char *

Code :

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

1
2
3
4
5
6
7
8
#ifndef _VA_LIST_DEFINED
#ifdef _M_CEE_PURE
typedef System::ArgIterator va_list;
#else
typedef char *  va_list;
#endif /* _M_CEE_PURE */
#define _VA_LIST_DEFINED
#endif

[Franck.H]

1) Pourquoi les fonctions vprintf prennent-elles en paramètre un argument de type va_list au lieu de va_list * ?

En fait, une va_list est déjà un pointeur, suivant les implémentation cela peut être un typedef sur un type void* ou pourquoi sous Unixoïdes peut-être même un pointeur sur une structure (sur ca je ne suis pas totalement sûr )

2) Quand on travaille dans un environnement où on ne peut pas utiliser d'allocation dynamique est-ce qu'il est dangereux d'utiliser ces fonctions/macros (va_start etc...) ? (est-ce que par exemple elles vont faire des malloc() ?)

Normalement c'est stocké dans la pile comme l'adresse de la fonction également et les autres variables locales et statiques donc non, pas d'allocation dynamique sinon ce serait sur le tas

[fearyourself]

Normalement c'est stocké dans la pile comme l'adresse de la fonction également et les autres variables locales et statiques donc non, pas d'allocation dynamique sinon ce serait sur le tas

Cela dépend de l'ABI de l'architecture. Mais je ne connais aucune architecture qui le ferait via un malloc/free donc, comme l'a dit Frank.h, ce n'est pas risqué.

Jc