#1 Le 15/11/2008, à 23:37
- Frankie_Lee
C -> Fonction execl/execlp, ce dernier argument?
Salut, je programme en C et je dois utiliser la fonctiosn execlp/execl mais je ne comprends pas du tout a quoi correspond le dernier argument de la fonction.
Si quelqu'un peut m'eclairer.
merci, bonne week end.
Hors ligne
#2 Le 15/11/2008, à 23:45
- tiky
Re : C -> Fonction execl/execlp, ce dernier argument?
man execl
Conseil d'expert: il vous faut un dentifrice adapté...
Hors ligne
#3 Le 16/11/2008, à 12:38
- rniamo
Re : C -> Fonction execl/execlp, ce dernier argument?
exec("ls","ls","-l",NULL);
1: tu dis que tu utilise ls
2: arg[0]=ls
3: arg[1]=-l
4: NULL = fin des arguments
< Quelques un des mes programmes | Cuisine Facile (pour les gourmands) | Fast MVC for PHP >
\ ^__^
\ (o o)\_______
(___)\ )\
Hors ligne
#4 Le 16/11/2008, à 14:03
- nicolas.sitbon
Re : C -> Fonction execl/execlp, ce dernier argument?
exec("ls","ls","-l",NULL);
1: tu dis que tu utilise ls
2: arg[0]=ls
3: arg[1]=-l
4: NULL = fin des arguments
c'était presque ça!
execl ("/bin/ls", "ls", "-l", (void*)0);
ou bien
execlp ("ls", "ls", "-l", (void*)0);
Hors ligne
#5 Le 16/11/2008, à 14:07
- tiky
Re : C -> Fonction execl/execlp, ce dernier argument?
rniamo a écrit :exec("ls","ls","-l",NULL);
1: tu dis que tu utilise ls
2: arg[0]=ls
3: arg[1]=-l
4: NULL = fin des argumentsc'était presque ça!
execl ("/bin/ls", "ls", "-l", (void*)0);
ou bien
execlp ("ls", "ls", "-l", (void*)0);
C'est presque presque ça
execl ("/bin/ls", "ls", "-l", (char *)NULL);
Lisez le man !
Conseil d'expert: il vous faut un dentifrice adapté...
Hors ligne
#6 Le 16/11/2008, à 14:28
- nicolas.sitbon
Re : C -> Fonction execl/execlp, ce dernier argument?
nicolas.sitbon a écrit :rniamo a écrit :exec("ls","ls","-l",NULL);
1: tu dis que tu utilise ls
2: arg[0]=ls
3: arg[1]=-l
4: NULL = fin des argumentsc'était presque ça!
execl ("/bin/ls", "ls", "-l", (void*)0);
ou bien
execlp ("ls", "ls", "-l", (void*)0);
C'est presque presque ça
execl ("/bin/ls", "ls", "-l", (char *)NULL);
Lisez le man !
plutôt que de lire le man, tu ferais bien de lire la norme...
((char*)NULL == (void*)0) != NULL
Hors ligne
#7 Le 16/11/2008, à 14:29
- tiky
Re : C -> Fonction execl/execlp, ce dernier argument?
Je sais bien que c'est la même chose mais ça parait plus logique de faire un cast char * dans ce cas. Et le prends pas aussi mal...
Dernière modification par tiky (Le 16/11/2008, à 14:30)
Conseil d'expert: il vous faut un dentifrice adapté...
Hors ligne
#8 Le 16/11/2008, à 14:35
- nicolas.sitbon
Re : C -> Fonction execl/execlp, ce dernier argument?
Explique moi ta logique de passer un (char*) alors qu'on attend un pointeur NULL. La meilleure définition de celui ci reste (void*)0.
Hors ligne
#9 Le 19/11/2008, à 11:13
- LittleJawa
Re : C -> Fonction execl/execlp, ce dernier argument?
Explique moi ta logique de passer un (char*) alors qu'on attend un pointeur NULL. La meilleure définition de celui ci reste (void*)0.
(char *) NULL est plus adapté dans le cas d'un appel à execl() parce que le MAN de execl le demande explicitement.
[...] The list of arguments must be terminated by a NULL pointer, and, since these are variadic functions, this pointer must be cast (char *) NULL. [...]
C'est pas un jugement de valeur, et personne ne dénigre ta logique, c'est juste qu'on suit la doc...
EDIT: par ailleurs, et là c'est une convention de développement C (cf. Kernighan & Ritchie), le mot clé "NULL" a été défini justement pour éviter de s'amuser à mettre des "(void *) 0" partout dans le code... Ca permet de clairement définir que l'on veut passer un pointeur nul, par opposition à une valeur 0 qui serait castée en pointeur.
Tout le monde sait que c'est la même chose. Mais à la lecture, c'est quand même plus intuitif de voir "NULL" que de voir "(void *) 0".
Mais bon : si tu codes tout seul dans ton coin et que personne ne relis ton code, tu es libre d'écrire ce que tu veux
Dernière modification par LittleJawa (Le 19/11/2008, à 11:21)
Hors ligne
#10 Le 19/11/2008, à 11:52
- nicolas.sitbon
Re : C -> Fonction execl/execlp, ce dernier argument?
nicolas.sitbon a écrit :Explique moi ta logique de passer un (char*) alors qu'on attend un pointeur NULL. La meilleure définition de celui ci reste (void*)0.
(char *) NULL est plus adapté dans le cas d'un appel à execl() parce que le MAN de execl le demande explicitement.
le man n'est pas la bonne doc, tu fais l'erreur de tous les linuxiens, la norme est la référence :
#include <unistd.h>
extern char **environ;
int execl(const char *path, const char *arg0, ... /*, (char *)0 */);
int execv(const char *path, char *const argv[]);
int execle(const char *path, const char *arg0, ... /*,
(char *)0, char *const envp[]*/);
int execve(const char *path, char *const argv[], char *const envp[]);
int execlp(const char *file, const char *arg0, ... /*, (char *)0 */);
int execvp(const char *file, char *const argv[]);
ici on voit clairement le bon cast : (char*)0 qui au passage à le même comportement que (void*)0, mais qui est différent de (char*)NULL (voir plus bas).
C'est pas un jugement de valeur, et personne ne dénigre ta logique, c'est juste qu'on suit la doc...
même remarque tu ne suis pas la bonne doc, revois tes sources.
EDIT: par ailleurs, et là c'est une convention de développement C (cf. Kernighan & Ritchie), le mot clé "NULL" a été défini justement pour éviter de s'amuser à mettre des "(void *) 0" partout dans le code... Ca permet de clairement définir que l'on veut passer un pointeur nul, par opposition à une valeur 0 qui serait castée en pointeur.
Tout le monde sait que c'est la même chose. Mais à la lecture, c'est quand même plus intuitif de voir "NULL" que de voir "(void *) 0".
Mais bon : si tu codes tout seul dans ton coin et que personne ne relis ton code, tu es libre d'écrire ce que tu veux
Plusieurs choses, le K&R n'est plus la référence depuis un petit moment déjà, encore une fois revois tes sources, on en est à la révision 3 (de septembre 2007) du standard C99 (ANSI, ISO, IEC). Dans la norme, rien n'empêche le mot clé NULL d'être défini ainsi :
#define NULL 0
Dans ce cas, le cast est obligatoire dans une fonction variadique qui attend un pointeur NULL en argument car le compilateur ne sait pas ce que l'on attend. Ainsi (void*)0 est portable à 100% et propre dans tous les cas. Ce qui n'est pas le cas de ton code. Si le pointeur NULL est défini chez toi ainsi
#define NULL (void*)0
, après la phrase de pré traitement par le préprocesseur, tu te retrouves avec des horreurs de ce style :
(char*)(void*)0
. Dans le cas de mon code, ça reste bien
(void*)0
.
On peut facilement se demander à quoi cela sert, mais quand on fait du développement professionnel un tant soit peu sérieux, on peut être amené à vérifier du code déjà traité par le préprocesseur.
Le C ne s'invente pas, et le man est à proscrire, rien de tel que la norme et l'expérience.
Hors ligne
#11 Le 19/11/2008, à 16:22
- Link31
Re : C -> Fonction execl/execlp, ce dernier argument?
après la phrase de pré traitement par le préprocesseur, tu te retrouves avec des horreurs de ce style
L'utilisation du préprocesseur est déjà une horreur en elle-même (sauf pour les ifdefs et les include guards). Le préprocesseur ne sert généralement en C qu'à masquer une syntaxe horrible derrière un nom facile à retenir. Quand on se retrouve obligé d'utiliser le préprocesseur, je ne pense pas que ça vaille encore la peine de s'interroger sur la "propreté" du code...
Dernière modification par Link31 (Le 19/11/2008, à 16:22)
Hors ligne
#12 Le 19/11/2008, à 16:29
- nicolas.sitbon
Re : C -> Fonction execl/execlp, ce dernier argument?
nicolas.sitbon a écrit :après la phrase de pré traitement par le préprocesseur, tu te retrouves avec des horreurs de ce style
L'utilisation du préprocesseur est déjà une horreur en elle-même (sauf pour les ifdefs et les include guards). Le préprocesseur ne sert généralement en C qu'à masquer une syntaxe horrible derrière un nom facile à retenir. Quand on se retrouve obligé d'utiliser le préprocesseur, je ne pense pas que ça vaille encore la peine de s'interroger sur la "propreté" du code...
Je reconnais là, la parole d'un développeur C++, et ne me dis pas le contraire! Moi je suis pour le pré processeur.
Hors ligne