[FAQ C] Donnez vos avis

[Melem]

Qu'en pensez-vous de la FAQ C ? N'hésitez surtout pas à poster des idées d'amélioration !

Pour contribuer (proposer une nouvelle question/réponse, soumettre un rapport de relecture, etc.), ouvrez une discussion dans le forum Contribuez.

[troumad]

Pour l'entrée : http://c.developpez.com/faq/?page=en...t#ENV_cmd_line , je proposerais de mettre un petit programme pour lister les variables :

Code :

1
2
3
4
5
6
7
8
9
10
11
#include <stdio.h>
 
int main(int argc, char * argv[], char * envp[])
{
            unsigned short i;
 
            for (i=0;envp[i]!=NULL;i++)
            {
                        printf("%s\n",envp[i]);
            }
}

[Melem]

Merci. Ton programme a été ajouté .

[troumad]

Toujours pour la même entrée, il faudrait signaler l’existence de la fonction getenv pour récupérer une variable d'environnement !

Code :

1
2
3
4
5
6
7
8
9
10
#include <stdio.h>
#include <stdlib.h>
 
int main()
{
        printf("HOME : %s\n",getenv("HOME"));
 	printf("HOMEPATH : %s\n",getenv("HOMEPATH"));
 
        return 0;
}

Normalement la première existe sous Linux et la seconde sous Windows. On test ainsi le retour de la fonction dans le cas où la variable existe et aussi quand elle n'existe pas (retour (null) ).

[Melem]

L'entrée parle déjà de la fonction getenv et même aussi de la fonction putenv (POSIX). La bonne entrée étant d'ailleurs celle-ci, celle que tu pointes ne concerne que les arguments de la ligne de commande (argc et argv). Et personnellement, je préfère la réponse actuelle qui ne propose aucun exemple d'utilisation de getenv puisqu'il faut déjà en connaître un minimum sur son OS pour s'intéresser à cette question, ou alors il faudra changer son titre. Si ça t'intéresse, tu peux proposer le nouveau titre et la réponse, ou peut-être directement une nouvelle Q/R.

[troumad]

Comment récupérer une variable d'environnement

La fonction getenv() permet de lire la valeur d'une variable d'environnement.

Code :

1
2
3
4
5
6
7
8
9
10
#include <stdio.h>
#include <stdlib.h>
 
int main()
{
        printf("HOME : %s\n",getenv("HOME"));
 	printf("HOMEPATH : %s\n",getenv("HOMEPATH"));
 
        return 0;
}

Normalement la première existe sous Linux et la seconde sous Windows. On teste ainsi le retour de la fonction dans le cas où la variable existe et aussi quand elle n'existe pas (retour (null) ).

La fonction putenv(), introduite par POSIX, permet quant à elle de créer ou de modifier une variable d'environnement.

Ces fonctions sont toutes déclarées dans stdlib.h.

Pour avoir la liste des variables d'environnement, vous pouvez regarder l'entrée Comment récupérer la listes des variables d'environnement ?


Comment récupérer la listes des variables d'environnement ?

Il existe aussi, sur certains compilateurs, une forme de déclaration de la fonction main() qui donne accès aux variables d'environnement via un paramètre de main().

Code :

1
2
3
4
int main(int argc, char * argv[], char * envp[])
{
    return 0;
}

envp pointe sur un tableau de pointeurs vers des chaînes de caractères, chacune représentant une variable d'environnement sous la forme : "nom=valeur", où nom correspond au nom de la variable et valeur à sa valeur. Le dernier élément du tableau pointé par envp contient NULL. Voici un petit programme qui liste les variables en utilisant le troisième argument de main :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
#include <stdio.h>
 
int main(int argc, char * argv[], char * envp[])
{
    unsigned short i;
 
    for(i = 0; envp[i] != NULL; i++)
    {
        printf("%s\n", envp[i]);
    }
 
    return 0;
}

Pour avoir une seulle variable d'environnement, il est plus simple de passer par Comment récupérer une variable d'environnement

[Melem]

Merci.
Fait .

[troumad]

Il manque une parenthèse à http://c.developpez.com/faq/?page=en...ment#ENV_popen

Code :

if ((pp = popen("ls -l", "r") == NULL)

doit être remplacé par

Code :

 if ((pp = popen("ls -l", "r")) == NULL)

Pour le commentaire juste avant, je mettrais une ponctuation après le dernier mot. Un simple point ou un deux points (. ou .

[Bktero]

Bonjour à tous,

Je viens de trouver un petit problème dans la FAQ C. Voici le mode opératoire pour le reproduire :

• Aller à l'adresse suivante : http://c.developpez.com/faq
• Recherche la phrase suivante : Comment déclarer un type qui fait référence à lui-même ?
• Le premier résultat correspond exactement aux critères de recherche.
• Essayer de cliquer dessus.

Résultat attendu :

• la page demandée est chargée et affichée.

Résultat obtenu :

• la page courante est rechargée et la page demandée ne s'affiche pas.

L'entrée ne semble pas exister dans la FAQ même si on la trouve avec l'outil de recherche.

Voilà

[Bktero]

On avait parler il y a peu de l'entrée de la FAQ donnant la fonction clean_stdin() et des problèmes qu'elle posait : http://www.developpez.net/forums/d12...h/#post6637337

Vous en aviez parlé il y a un an : http://www.developpez.net/forums/d10...r/#post5982737

[Bktero]

Bonjour,

Je rajoute ici un autre problème de la FAQ, dont j'avais déjà parlé avec diogene.

En comparant cette entrée de la FAQ :
http://c.developpez.com/faq/index.ph...RINGS_numtostr

à ce qu'on peut lire sur la page de man de la fonction strtol, je constate qu'il y a une condition de plus dans le man :

En particulier, si *nptr n'est pas `\0' et si **endptr vaut `\0' en retour, la chaîne entière est valide.

De plus, le code de la FAQ ne gère pas les dépassements de format.

Il serait utile de préciser ces cas dans la FAQ, au moins pour que le lecteur ait conscience de ces cas particuliers.

[Melem]

Sur clean_stdin : la fonction est correcte, me semble t-il. C'est l'usage que certaines personnes en font qui est incorrecte. Mais on pourrait peut-être rajouter un lien vers la FAQ juste au dessus pour un exemple d'utilisation ?

Sur la conversion de chaîne en nombre : on en avait déjà en effet parlé. Je mettrai à jour dès que possible pour tenir compte de tes remarques.

[Bktero]

Je suis d'accord : la fonction est correcte. Elle a néanmoins un cadre d'utilisation certains : il faut être sûr que le buffer contienne un caractère, sinon c'est boucle infinie. L'utilisation qu'on peut en faire est restreinte, on ne peut l'utiliser qu'après erreur et non en préventif pour vider le buffer clavier. Il sera bon de préciser cela, au moins.

[Obsidian]

Hello à tous,

Je voudrais rebondir à mon tour sur les entrées « À quoi sert la fonction fflush() » et « comment vider le buffer clavier », et notamment sur les messages que Bktero a eu la gentillesse d'indiquer.

Pour le premier point (à quoi ça sert), la norme dit que le comportement d'un fflush() sur un flux entrant est indéfini. Je trouve qu'il serait bon d'expliquer également que fflush() a vocation à provoquer l'envoi immédiat des données en attente vers leur destinataire et pas à détruire en soi le contenu du buffer. Par conséquent, le destinataire d'un flux entrant est justement le processus qui appelle fflush() et l'opération n'a donc pas de sens. Plus précisément, si celui-ci ne lit pas les caractères à sa disposition, il n'y a aucune raison pour qu'ils bougent.

Le comportement le plus « logique » à adopter dans ce cas consiste donc à ne rien faire. C'est l'attitude adoptée notamment par GNU. D'autres implémentations, elles, profitent justement du flou laissé par la norme pour implémenter justement un vidage de buffer et c'est une mauvaise chose pour deux raisons. La première, c'est que cette implémentation est basée sur la même supposition erronée que font les débutants, et que si ceux-ci prennent d'emblée l'habitude d'écrire des programmes en vidant le buffer clavier de cette façon, alors il faudra tous les reprendre un par un lorsqu'on voudra les porter. La seconde, c'est qu'en suivant cette logique, un « fflush(stdout) » ou sur n'importe quel flux de sortie devrait avoir le même comportement : détruire les données encore en attente passé un certain stade. Et ce n'est clairement pas le cas, ni l'objet de la fonction.


En ce qui concerne le second point (comment vider le buffer), on ne peut pas considérer la fonction « clean_stdin() » actuelle comme correcte parce que non seulement elle impose une action particulière de l'utilisateur (l'entrée d'un retour à la ligne) mais qu'une lecture sur un buffer clavier vide ne renvoie pas EOF mais bloque. Et donc :

• Soit le buffer contient déjà plusieurs retours à la ligne et, dans ce cas, le buffer n'est pas entièrement vidé ;
• Soit le buffer ne contient aucun retour à la ligne et on reste coincé dans une boucle infinie comme signalé ci-dessus ;
• Si l'utilisateur est suffisamment malin pour comprendre à quoi il a affaire et qu'il saisit un retour à la ligne ou un Ctrl-D — sur une ligne vide — il faudrait quand même qu'il connaisse l'état antérieur du buffer pour savoir si c'est la fonction de vidage qui va le traiter ou, au contraire, le programme légitime qui suit l'appel à cette fonction.

L'idéal serait de pouvoir agir directement sur le buffer associé au flux mais C99 (au moins) précise que setvbuf() ne peut être appelée que si aucune autre opération (autre qu'un setvbuf() échoué) n'a encore eu lieu sur le fichier concerné.

Je pense que ce n'est pas faisable en C standard mais, à la fin du message en question, je proposais un programme compatible POSIX. L'idée s'appuie sur le fait qu'on considère le buffer de l'entrée standard comme vide qu'à partir du moment où la lecture d'un caractère supplémentaire serait bloquante. Et pour vérifier cela, la fonction en question acquiert les flags du flux, le passe en non-bloquant, et fait des lectures par blocs dans un buffer local jusqu'à obtenir EWOULDBLOCK, puis restaure les flags avant de sortir.

Il faudrait simplement, en plus, s'assurer au préalable que l'entrée standard est associée à un flux interactif.

[leternel]

bonjour à tous,
Grace à _-Slash-_ et son sujet Comparaison de doubles, il y a une erreur dans la faq, à la question comment comparer des doubles

si le premier nombre (a) est négatif, la différence b-a est positive, et le quotient (b-a)/a est négatif, donc toujours plus petit qu'un ratio sensément positif.
Je suggère d'introduire soit un conditionnel (? soit un fabs()

Code :

1
2
3
4
5
6
7
8
 
        if (ret != 0)
        {
            /* Si on a encore ret != 0 (i.e. x != y), utiliser eps_r. */
 
            if ( fabs((b - a) / a) < eps_r)
                ret = 0;
        }

par ailleurs, ce code peut mener à une division par 0

[_-Slash-_]

Ou peut-être indiquer les propositions de D. KNUTH (ici, double à la place de float):

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
bool approximatelyEqual(double a, double b, double epsilon)
{
    return fabs(a - b) <= ( (fabs(a) < fabs(b) ? fabs(b) : fabs(a)) * epsilon);
}
 
bool essentiallyEqual(double a, double b, double epsilon)
{
    return fabs(a - b) <= ( (fabs(a) > fabs(b) ? fabs(b) : fabs(a)) * epsilon);
}
 
bool definitelyGreaterThan(double a, double b, double epsilon)
{
    return (a - b) > ( (fabs(a) < fabs(b) ? fabs(b) : fabs(a)) * epsilon);
}
 
bool definitelyLessThan(double a, double b, double epsilon)
{
    return (b - a) > ( (fabs(a) < fabs(b) ? fabs(b) : fabs(a)) * epsilon);
}

[Médinoc]

Ceci devrait être plus lisible avec min et max, non?

Code C :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
//Insérer ce qu'il faut pour avoir un min et un max
 
bool approximatelyEqual(double a, double b, double epsilon)
{
    return fabs(a - b) <= (max(fabs(a), fabs(b)) * epsilon);
}
 
bool essentiallyEqual(double a, double b, double epsilon)
{
    return fabs(a - b) <= (min(fabs(a), fabs(b)) * epsilon);
}
 
bool definitelyGreaterThan(double a, double b, double epsilon)
{
    return (a - b) > (max(fabs(a), fabs(b)) * epsilon);
}
 
bool definitelyLessThan(double a, double b, double epsilon)
{
    return (b - a) > (max(fabs(a), fabs(b)) * epsilon);
}