Le 11/09/06 20:54, dans <4505b0e6$0$27393$, « gl » a écrit :
int main(int argc, char *argv[], char *envp[])
C'est défini au paragraphe J.5.1 de la norme. Mais pour que cette fonction soit portable il faut effectivement que le système le supporte :-)
Dans le paragraphe "Common extensions". Ce n'est pas une forme normalisée et imposée par la norme mais une extension courante (comme indiqué dans mon message précédent).
Oui je sais. La norme dit "... extensions... are not portable to all implementations". Cela suppose donc que c'est portable sur certaines architectures, et là on trouve tout ce qui est posix de prêt ou de loin.
Une implémentation est libre ne pas la proposer voire de proposer une extension syntaxiquement semblable avec un sens totalement différent (ce qui serait particulièrement malvenu).
Oui, très malvenu. Connais-tu une seule telle implémentation ? Je ne parle pas du cas ou envp n'est pas présent, j'en connais, mais d'implémentations ou le envp n'a pas la syntaxe posix ?
Ce n'est pas 100% portable même si il est vrai qu'il y a de fortes chances de rencontrer cette extension, qui reste malgré tout la meilleure des solutions (dans les cas où getenv() ne convient pas bien entendu).
Voilà.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 11/09/06 20:54, dans <4505b0e6$0$27393$ba4acef3@news.orange.fr>, « gl »
<gl@gl.fr> a écrit :
int main(int argc, char *argv[], char *envp[])
C'est défini au paragraphe J.5.1 de la norme. Mais pour que cette fonction
soit portable il faut effectivement que le système le supporte :-)
Dans le paragraphe "Common extensions". Ce n'est pas une forme
normalisée et imposée par la norme mais une extension courante (comme
indiqué dans mon message précédent).
Oui je sais. La norme dit "... extensions... are not portable to all
implementations". Cela suppose donc que c'est portable sur certaines
architectures, et là on trouve tout ce qui est posix de prêt ou de loin.
Une implémentation est libre ne pas la proposer voire de proposer une
extension syntaxiquement semblable avec un sens totalement différent (ce
qui serait particulièrement malvenu).
Oui, très malvenu. Connais-tu une seule telle implémentation ? Je ne parle
pas du cas ou envp n'est pas présent, j'en connais, mais d'implémentations
ou le envp n'a pas la syntaxe posix ?
Ce n'est pas 100% portable même si il est vrai qu'il y a de fortes
chances de rencontrer cette extension, qui reste malgré tout la
meilleure des solutions (dans les cas où getenv() ne convient pas bien
entendu).
Voilà.
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 11/09/06 20:54, dans <4505b0e6$0$27393$, « gl » a écrit :
int main(int argc, char *argv[], char *envp[])
C'est défini au paragraphe J.5.1 de la norme. Mais pour que cette fonction soit portable il faut effectivement que le système le supporte :-)
Dans le paragraphe "Common extensions". Ce n'est pas une forme normalisée et imposée par la norme mais une extension courante (comme indiqué dans mon message précédent).
Oui je sais. La norme dit "... extensions... are not portable to all implementations". Cela suppose donc que c'est portable sur certaines architectures, et là on trouve tout ce qui est posix de prêt ou de loin.
Une implémentation est libre ne pas la proposer voire de proposer une extension syntaxiquement semblable avec un sens totalement différent (ce qui serait particulièrement malvenu).
Oui, très malvenu. Connais-tu une seule telle implémentation ? Je ne parle pas du cas ou envp n'est pas présent, j'en connais, mais d'implémentations ou le envp n'a pas la syntaxe posix ?
Ce n'est pas 100% portable même si il est vrai qu'il y a de fortes chances de rencontrer cette extension, qui reste malgré tout la meilleure des solutions (dans les cas où getenv() ne convient pas bien entendu).
Voilà.
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
gl
Ce n'est pas 100% portable même si il est vrai qu'il y a de fortes chances de rencontrer cette extension, qui reste malgré tout la meilleure des solutions (dans les cas où getenv() ne convient pas bien entendu).
Et si cette extension est présente sur les différentes plate-formes cibles bien évidemment.
Ce n'est pas 100% portable même si il est vrai qu'il y a de fortes
chances de rencontrer cette extension, qui reste malgré tout la
meilleure des solutions (dans les cas où getenv() ne convient pas bien
entendu).
Et si cette extension est présente sur les différentes plate-formes
cibles bien évidemment.
Ce n'est pas 100% portable même si il est vrai qu'il y a de fortes chances de rencontrer cette extension, qui reste malgré tout la meilleure des solutions (dans les cas où getenv() ne convient pas bien entendu).
Et si cette extension est présente sur les différentes plate-formes cibles bien évidemment.
gl
Une implémentation est libre ne pas la proposer voire de proposer une extension syntaxiquement semblable avec un sens totalement différent (ce qui serait particulièrement malvenu).
Oui, très malvenu. Connais-tu une seule telle implémentation ? Je ne parle pas du cas ou envp n'est pas présent, j'en connais, mais d'implémentations ou le envp n'a pas la syntaxe posix ?
Je dirais plutôt une "implémentation où main() accepte un troisième
paramètre char** qui n'est pas la liste des variables d'environnement". Non je n'en connais pas (et je pense qu'il est peu probable d'en rencontrer), mais rien ne l'empêche.
Ce n'est pas 100% portable même si il est vrai qu'il y a de fortes chances de rencontrer cette extension, qui reste malgré tout la meilleure des solutions (dans les cas où getenv() ne convient pas bien entendu).
Voilà.
Je n'avais pas voulu dire autre chose dans ma première intervention. Je m'excuses si ce n'était pas clair.
Une implémentation est libre ne pas la proposer voire de proposer une
extension syntaxiquement semblable avec un sens totalement différent (ce
qui serait particulièrement malvenu).
Oui, très malvenu. Connais-tu une seule telle implémentation ? Je ne parle
pas du cas ou envp n'est pas présent, j'en connais, mais d'implémentations
ou le envp n'a pas la syntaxe posix ?
Je dirais plutôt une "implémentation où main() accepte un troisième
paramètre char** qui n'est pas la liste des variables d'environnement".
Non je n'en connais pas (et je pense qu'il est peu probable d'en
rencontrer), mais rien ne l'empêche.
Ce n'est pas 100% portable même si il est vrai qu'il y a de fortes
chances de rencontrer cette extension, qui reste malgré tout la
meilleure des solutions (dans les cas où getenv() ne convient pas bien
entendu).
Voilà.
Je n'avais pas voulu dire autre chose dans ma première intervention. Je
m'excuses si ce n'était pas clair.
Une implémentation est libre ne pas la proposer voire de proposer une extension syntaxiquement semblable avec un sens totalement différent (ce qui serait particulièrement malvenu).
Oui, très malvenu. Connais-tu une seule telle implémentation ? Je ne parle pas du cas ou envp n'est pas présent, j'en connais, mais d'implémentations ou le envp n'a pas la syntaxe posix ?
Je dirais plutôt une "implémentation où main() accepte un troisième
paramètre char** qui n'est pas la liste des variables d'environnement". Non je n'en connais pas (et je pense qu'il est peu probable d'en rencontrer), mais rien ne l'empêche.
Ce n'est pas 100% portable même si il est vrai qu'il y a de fortes chances de rencontrer cette extension, qui reste malgré tout la meilleure des solutions (dans les cas où getenv() ne convient pas bien entendu).
Voilà.
Je n'avais pas voulu dire autre chose dans ma première intervention. Je m'excuses si ce n'était pas clair.
