Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Langage C transformer un tampon en lignes

transformer un tampon en lignes

56 réponses
Avatar
Benoit Izac
Bonjour,

Je cherche à faire une fonction qui me permette de transformer un tampon
en lignes de façon à traiter ces dernières par la suite.

J'ai un bout de code qui fonctionne :
========================================================================
#include <stdio.h>
#include <stdlib.h>

#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

#define BS 10
#define LM 100

int get_line(const char *buffer, size_t *bp, size_t bs,
char *line, size_t *lp, size_t ls)
{
while (*bp < bs) {
/* not enough space in line */
if (!(*lp < ls)) {
(*bp)--;
line[(*lp)-1] = 0;
(*lp) = 0;
return -1;
}
/* end of file? */
if (buffer[*bp] == EOF) {
printf("end of file?\n");
line[*lp] = 0;
return 0;
}
/* end of line */
if (buffer[*bp] == '\n') {
line[*lp] = 0;
(*lp) = 0;
(*bp)++;
return 1;
}
line[*lp] = buffer[*bp];
(*lp)++;
(*bp)++;
}
/* end of buffer */
(*bp) = 0;
line[*lp] = 0;
return 0;
}


int main(int argc, char *argv[])
{
int fd;
size_t r;
char buf[BS];
char line[LM];
size_t bp = 0;
size_t lp = 0;

if (argc != 2)
exit(1);

fd = open(argv[1], O_RDONLY);
if (fd < 0)
exit(2);

while((r = read(fd, buf, BS))) {
while (get_line(buf, &bp, r, line, &lp, LM))
printf("%s\n", line);
}

close(fd);
return 0;
}
========================================================================
PS : Désolé pour ceux qui ne sont pas sous Unix, j'ai bien essayé de
faire la même chose avec fread() mais cette dernière ne me renvoie pas
la taille lu, ce qui pose un problème à la dernière lecture où r est la
plupart du temps différent de BS.

Mon choix lorsque la taille de line est trop petite est discutable
(vaut-il mieux tronquer les lignes ?) mais ce n'est pas vraiment ce qui
me pose problème.

Les questions :
* Ce code est-il correct (fonctionne-t-il dans tous les cas) ?
* Est-il possible d'alléger le code (que get_line est moins
d'arguments) en déclarant bp et lp static ?
* Existe-t-il une autre solution (fonction toute faite, autre
algorithme) ?

Merci.
--
Benoit Izac
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3 4 5
Avatar
Benoit Izac
Bonjour,

le 30/07/2010 à 23:13, xtof pernod a écrit dans le message
<4c534065$0$10201$ :

Conclusions :
* les lignes avec juste un 'n' sont supprimées



Euh, oui, normal.. pas de token entre 2 délimiteurs de suite.



Pour mon usage, ce n'est pas gênant, mais il faut être conscient que
ce n'est pas une solution universelle.



? ben.. Ca fait bien ce que ça dit. Et en toute logique, plusieurs
délimiteurs de suite n'encadrent aucun "token", et donc ça ne retourne
rien.



Non. Les exemples que j'ai posté te permette de faire :
$ gcc a.c && ./a.out a.c > b.c && diff a.c b.c && echo OK
OK

Il n'y a pas de modification de ce qui est lu dans le buffer.

Essaye autre chose si ça te convient pas..



C'est ce que je fais depuis un petit moment.

* si len (la taille de buff) est trop petite pour avoir une ligne
entière, la ligne est coupée



Là, je dirais que c'est à toi de prévoir suffisamment grand.



Je pense qu'il y a moyen de faire ça avec archive_entry_size() pour
avoir sa taille, d'allouer puis de faire le archive_read_data(). Mais
bon, ça veut dire mettre un fichier entier en mémoire à chaque fois.
Je vais quand même tester pour voir.



Comme tu veux, mais àma tu te compliques la vie.



Comment faire autrement puisque si mon buffer est trop petit, les
résultats sont faux ?

Donc, soit je ne sais pas l'utiliser, soit ça ne me convient pas.



Tout n'est pas perdu: dans "SEE ALSO", il cite strchr et index
(entre autres) mais celles ci devraient faire ton bonheur.



Ce serait plutôt memchr() dans mon cas mais je ne vois pas ce que ça



Implicitement, "lignes" + 'n' veut dire que tu traines des chaines de
caractères imprimables (surtout que tu les sorts au printf()); mem*(),
c'est pour des données quelconques et/ou binaires. A toi de voir.

change par rapport au parcourt du buffer que je faisais précédemment.



Euh, quel parcours, de quelle version ?!



<news:
<http://groups.google.fr/group/fr.comp.lang.c/msg/e8dfd7106fb7869a>

<news:
<http://groups.google.fr/group/fr.comp.lang.c/msg/6c93f613b851a4ac>

Dans tous les cas, memchr(), va parcourir la chaîne, puis memcpy() va
le faire aussi.



Certes, mais là tu t'embêtes avec des points de détail. Combien de
temps cpu, pour scruter quelques dizaines d'octets ?



Il s'agit de 80 Mo de données, ce n'est pas négligeable.

--
Benoit Izac
Avatar
xtof pernod
Le 30/07/2010 23:22, Marc Espie a fait rien qu'à écrire:
In article <4c533f6e$0$10196$,
xtof pernod wrote:
Pour S_IRUSR, S_IWUSR & S_IXUSR etc. dans le cas où open(), avec O_CREAT,
a besoin du 3eme parametre (mode).

Sauf qu'en général on met 0640, et stat.h ne sert pas..



0640 ? Ah non, 0666 le plus souvent. umask(2), c'est pas fait pour les
chiens...



WaF ? Tu mets un umask(2) partout où tu utilises open() ?
J'ai juste umask 066 dans le .profile de root, le reste...

Bon, en tout cas, j'ai jamais vu de
creat(...,S_IRUSR | S_IWUSR | S_IRGRP | S_IWGRP | S_IROTH | S_IWOTH)
d'où la faible utilité de stat.h juste pour open, mais le man se veut
exhasutif..

--
christophe.
Avatar
xtof pernod
Le 30/07/2010 23:35, Benoit Izac a fait rien qu'à écrire:
Bonjour,



Bonsoir,


le 30/07/2010 à 23:13, xtof pernod a écrit dans le message
<4c534065$0$10201$ :

Conclusions :
* les lignes avec juste un 'n' sont supprimées



Euh, oui, normal.. pas de token entre 2 délimiteurs de suite.



Pour mon usage, ce n'est pas gênant, mais il faut être conscient que
ce n'est pas une solution universelle.



? ben.. Ca fait bien ce que ça dit. Et en toute logique, plusieurs
délimiteurs de suite n'encadrent aucun "token", et donc ça ne retourne
rien.



Non. Les exemples que j'ai posté te permette de faire :
$ gcc a.c && ./a.out a.c > b.c && diff a.c b.c && echo OK
OK

Il n'y a pas de modification de ce qui est lu dans le buffer.

Essaye autre chose si ça te convient pas..



C'est ce que je fais depuis un petit moment.




Je vois bien. Le pb a pourtant pas l'air compliqué, je pense que 10 lignes
de codes devraient suffire, à moins que j'ai loupé un truc.

Faut dire aussi que les infos arrivent un peu au compte-goutte..

* si len (la taille de buff) est trop petite pour avoir une ligne
entière, la ligne est coupée



Là, je dirais que c'est à toi de prévoir suffisamment grand.



Je pense qu'il y a moyen de faire ça avec archive_entry_size() pour
avoir sa taille, d'allouer puis de faire le archive_read_data(). Mais
bon, ça veut dire mettre un fichier entier en mémoire à chaque fois.
Je vais quand même tester pour voir.



Comme tu veux, mais àma tu te compliques la vie.



Comment faire autrement puisque si mon buffer est trop petit, les
résultats sont faux ?




Le dimensionner suffisament grand ? Excuse moi, mais ma boule de
cristal ne m'a pas révélé à quoi ressemblait tes données.

Je suppose toujours que c'est des chaines, vu que tu emploies printf().

Donc, soit je ne sais pas l'utiliser, soit ça ne me convient pas.



Tout n'est pas perdu: dans "SEE ALSO", il cite strchr et index
(entre autres) mais celles ci devraient faire ton bonheur.



Ce serait plutôt memchr() dans mon cas mais je ne vois pas ce que ça



Implicitement, "lignes" + 'n' veut dire que tu traines des chaines de
caractères imprimables (surtout que tu les sorts au printf()); mem*(),
c'est pour des données quelconques et/ou binaires. A toi de voir.

change par rapport au parcourt du buffer que je faisais précédemment.



Euh, quel parcours, de quelle version ?!



<news:
<http://groups.google.fr/group/fr.comp.lang.c/msg/e8dfd7106fb7869a>

<news:
<http://groups.google.fr/group/fr.comp.lang.c/msg/6c93f613b851a4ac>

Dans tous les cas, memchr(), va parcourir la chaîne, puis memcpy() va
le faire aussi.



Certes, mais là tu t'embêtes avec des points de détail. Combien de
temps cpu, pour scruter quelques dizaines d'octets ?



Il s'agit de 80 Mo de données, ce n'est pas négligeable.




Fais déja un bon programme avant de te soucier des fonctions de la
bib' standard du C. Elles ont été optimisées au max., le compilateur
(gcc et d'autres) fait un bon boulot surtout pour mem*().


A titre indicatif: à 1,7GHz:

:/mnt/src/fsv# time dd if=/dev/zero bs=1M of=/dev/null count€
80+0 enregistrements lus
80+0 enregistrements écrits
83886080 octets (84 MB) copiés, 0,0333788 s, 2,5 GB/s
real 0m0.050s
user 0m0.004s <-
sys 0m0.020s <-

ce qui est de l'ordre du négligeable, pour copier 80Mo de données.

--
christophe.
Avatar
espie
In article <4c5348fd$0$10197$,
xtof pernod wrote:
Le 30/07/2010 23:22, Marc Espie a fait rien qu'à écrire:
In article <4c533f6e$0$10196$,
xtof pernod wrote:
Pour S_IRUSR, S_IWUSR & S_IXUSR etc. dans le cas où open(), avec O_CREAT,
a besoin du 3eme parametre (mode).

Sauf qu'en général on met 0640, et stat.h ne sert pas..



0640 ? Ah non, 0666 le plus souvent. umask(2), c'est pas fait pour les
chiens...



WaF ? Tu mets un umask(2) partout où tu utilises open() ?
J'ai juste umask 066 dans le .profile de root, le reste...



Non, mais je cree mes fichiers avec open(..., 0666) sauf raison specifique
(par exemple, fichier qui *doit* etre prive. Typiquement, une application
qui sauve des mails avec autre chose que 0600 est un peu buggue).

C'est pas a l'appli d'etre parano, mais a l'utilisateur. Un utilisateur
normal aura 022 comme umask. S'il a autre chose, c'est son probleme, et
c'est pas a ton programme de decider a sa place !
Avatar
Benoit Izac
Bonjour,

le 31/07/2010 à 00:19, xtof pernod a écrit dans le message
<4c535001$0$10191$ :

Je vois bien. Le pb a pourtant pas l'air compliqué, je pense que 10 lignes
de codes devraient suffire, à moins que j'ai loupé un truc.

Faut dire aussi que les infos arrivent un peu au compte-goutte..



Faut pas exagérer non plus. Je reconnais que je me suis viandé avec
fread(), ce qui a provoqué plus de réponses concernant read/open que sur
le problème en lui-même. Maintenant, l'objet du message me parait plutôt
explicite : « transformer un tampon en lignes ».

Concernant la solution au programme qui utilise la libarchive, je l'ai
trouvée avant de poster ce message. Ce qui m'ennuie c'est que le code
ressemble à ça :
{
while (archive_read_next_header(a, &ae) == ARCHIVE_OK) {
[...]
j = 0;
while ((r = archive_read_data(a, buf, bs))) {
for (i = 0; buf[i] && i < r; i++)
if (buf[i] == 'n') {
line[j] = 0;
j = 0;
if (match(line, pattern)) {
encore des tests sur d'autre choses
traitement
}
}
line[j] = buf[i];
j++;
i++;
}
}
}
}

J'ai une indentation de 4 espaces, si j'en avais 8, je serais en dehors
de la page. Je cherche donc à mettre tout ce traitement dans une
fonction de manière à avoir un code plus lisible et donc plus
maintenable.

Tant qu'à faire une fonction, autant qu'elle puisse me resservir pour
plus tard. Je cherche donc à faire un truc générique.

En entrée, au minimum :
* le buffer
* sa taille
* un espace pour stocker la ligne en cours

En sortie :
* NULL si le buffer est vide pour faire une autre lecture des données
ou
-1 = erreur (ligne trop courte par exemple)
0 = buffer vide
0 = taille de la ligne ? taille des données restant dans le buffer ?

Comment faire autrement puisque si mon buffer est trop petit, les
résultats sont faux ?



Le dimensionner suffisament grand ? Excuse moi, mais ma boule de
cristal ne m'a pas révélé à quoi ressemblait tes données.



Je viens de regarder, le plus grand fichier texte que j'ai à lire fait
5 Mo. Mais encore une fois, je ne peux pas le savoir à l'avance (sauf
avec archive_entry_size()) et peut-être que demain il fera 10 Mo.

Je suppose toujours que c'est des chaines, vu que tu emploies printf().



Ce ne sont que des fichiers texte sur lequel je fais un traitement ligne
par ligne (recherche d'un motif, soit avec strstr() soir avec
regexec() mais ça pourrait être autre chose).

Fais déja un bon programme avant de te soucier des fonctions de la
bib' standard du C. Elles ont été optimisées au max., le compilateur
(gcc et d'autres) fait un bon boulot surtout pour mem*().



Je ne me soucie pas de la bibliothèque standard, mais je constate qu'en
fonction des différentes implémentations que j'ai faites, que les
différences sont significatives : moins de 2 secondes dans le meilleur
des cas, 6 secondes dans le pire des cas. Bon j'ai même été jusqu'à 30
secondes car je faisais les regcomp/regfree dans la boucle alors qu'il
suffit de le faire une fois. Après tout est relatif...

--
Benoit Izac
Avatar
Samuel DEVULDER
Alexandre Bacquart a écrit :

Avec ça, ton prototype initial :

extern void plot(int color, int y, int x);

...n'est qu'une vulgaire blague pour n'importe qui a déjà mis les pieds
dans une bibliothèque graphique.



Oui, tout à fait, c'est un exemple. Ca vaut pour tout autre contexte.
Une biblio graphique typique utilisera un graphic-context (GC) plutôt.

Toutes celles que je connais ont la
Si tu as vu y,x ailleurs, dis-moi où que je
l'évite à tout prix.



:) c'était un exemple. Tu peux substituer plot à n'importe quel
fonction. Une bibliothèque d'acquisition d'image, d'accès à une base de
donnée etc, ce que tu veux. Le propos n'est pas de discuter autour d'une
implémentation de plot(), mais de montrer comment on peut en C regrouper
plusieurs paramètres dans une struct, et des avantages qu'on peut en
tirer pour la lisibilité.

...mais me plaît beaucoup moins que :

color(3);
plot(12, 128);



Note que ici ton état contenant la couleur doit être stocké dans une var
statique. Si tu travailles en mode multi-thread il n'est pas exclus
qu'un autre thread ait appelé color(4) entre tes deux appels.
L'utilisation d'un GC par thread évite ce problème.

sam.
Avatar
xtof pernod
Le 31/07/2010 00:37, Marc Espie a fait rien qu'à écrire:
In article <4c5348fd$0$10197$,
xtof pernod wrote:
Le 30/07/2010 23:22, Marc Espie a fait rien qu'à écrire:
In article <4c533f6e$0$10196$,
xtof pernod wrote:
Pour S_IRUSR, S_IWUSR & S_IXUSR etc. dans le cas où open(), avec O_CREAT,
a besoin du 3eme parametre (mode).

Sauf qu'en général on met 0640, et stat.h ne sert pas..



0640 ? Ah non, 0666 le plus souvent. umask(2), c'est pas fait pour les
chiens...





WaF ? Tu mets un umask(2) partout où tu utilises open() ?
J'ai juste umask 066 dans le .profile de root, le reste...



Non, mais je cree mes fichiers avec open(..., 0666) sauf raison specifique
(par exemple, fichier qui *doit* etre prive. Typiquement, une application
qui sauve des mails avec autre chose que 0600 est un peu buggue).

C'est pas a l'appli d'etre parano,



Je dirais que c'est au programmeur. L'appli, elle, est programmée pour en
avoir rien à foutre. Ce qu'elle fait avec le plus grand bonheur..

mais a l'utilisateur. Un utilisateur



Euh.. Si tu peux parler à tes utilisateurs de perm. en octal ,
pas de doute, c'est de la balle^W^W^W. l'idéal.
Mais c'est plutôt rare dans le cas général...

normal aura 022 comme umask. S'il a autre chose, c'est son probleme, et
c'est pas a ton programme de decider a sa place !



Bon.. On va peut-être pas trétrasectionner pour 022 euroctals, si ?
Ou alors au comptoir. fu2 pré-postionné, il y a plein de gens inspirés.

--
christophe.
Avatar
xtof pernod
Le 31/07/2010 01:13, Benoit Izac a fait rien qu'à écrire:
le 31/07/2010 à 00:19, xtof pernod a écrit dans le message
<4c535001$0$10191$ :
(...)
Faut dire aussi que les infos arrivent un peu au compte-goutte..



Faut pas exagérer non plus. Je reconnais que je me suis viandé avec



Le prend pas mal hein. Juste, tu as commencé avec des lectures non
bufferisées, puis bufferisées, puis en fait c'était un tampon, pis
après on apprend que ça vient d'un fonction d'une bibliothèque..

Ca aide pas à te faire une réponse précise =)

fread(), ce qui a provoqué plus de réponses concernant read/open que sur
le problème en lui-même. Maintenant, l'objet du message me parait plutôt
explicite : « transformer un tampon en lignes ».



Auquel tu rajoutes des contraintes (taille buff, fonctions de la libc
qui te vont pas, je sais tj pas pourquoi).

C'est peut-être clair pour toi, nettement moins pour moi.


Concernant la solution au programme qui utilise la libarchive, je l'ai
trouvée avant de poster ce message. Ce qui m'ennuie c'est que le code
ressemble à ça :
(snip)

J'ai une indentation de 4 espaces,



Tu as un 'coding-style', et tu t'y tiens: rien à redire.

si j'en avais 8, je serais en dehors
de la page.



Oui, mais comme c'est parti tu risque d'y arriver. Réduire encore
la tabulation à encore moins n'est pas une soluce àma.

Je cherche donc à mettre tout ce traitement dans une
fonction de manière à avoir un code plus lisible et donc plus
maintenable.

Tant qu'à faire une fonction, autant qu'elle puisse me resservir pour
plus tard. Je cherche donc à faire un truc générique.

En entrée, au minimum :
* le buffer
* sa taille
* un espace pour stocker la ligne en cours

En sortie :
* NULL si le buffer est vide pour faire une autre lecture des données
ou
-1 = erreur (ligne trop courte par exemple)
0 = buffer vide
>0 = taille de la ligne ? taille des données restant dans le buffer ?




Mouais.. le pb, c'est que, comme tu as pu le constater toi même, c'est
que ça donne une fonction extrenement compliquée, avec des paramètres en
pagailles, variables statiques et autres joyeusetés. Pas facile à maintenir.

[ref: une fonction geline() que tu emploirais comme :
while (line = getline(buf, len)) { ... }]

En plus, écrite comme ça, la fonction risque de ne pouvoir servir qu'une
seule fois par programme. A cause des static que tu ne peux réinitialiser.

Alors qu'avec str*(), un découpage propre & net peut se faire en (moins de)
10 instructions. Mais fais toi ta propre idée, ça vaudra mieux que tout
ce que je pourrais te dire..

Comment faire autrement puisque si mon buffer est trop petit, les
résultats sont faux ?



Le dimensionner suffisament grand ? Excuse moi, mais ma boule de
cristal ne m'a pas révélé à quoi ressemblait tes données.



Je viens de regarder, le plus grand fichier texte que j'ai à lire fait
5 Mo. Mais encore une fois, je ne peux pas le savoir à l'avance (sauf



(sinon ça serait trop facile)

avec archive_entry_size()) et peut-être que demain il fera 10 Mo.



Ah ben voila. C'est le genre d'info qui peut aiguiller sur un algo ou
un autre.

Encore que, bosser avec un gros buffer, du moment qu'il n'est pas
plus grand que la mémoire physique, ça me pose pas plus de soucis.


Je suppose toujours que c'est des chaines, vu que tu emploies printf().



Ce ne sont que des fichiers texte sur lequel je fais un traitement ligne
par ligne (recherche d'un motif, soit avec strstr() soir avec
regexec() mais ça pourrait être autre chose).



Hum.. je suis même pas persuadé que le découpage en ligne soit nécessaire.

Fais déja un bon programme avant de te soucier des fonctions de la
bib' standard du C. Elles ont été optimisées au max., le compilateur
(gcc et d'autres) fait un bon boulot surtout pour mem*().



Je ne me soucie pas de la bibliothèque standard, mais je constate qu'en
fonction des différentes implémentations que j'ai faites, que les
différences sont significatives : moins de 2 secondes dans le meilleur



Eh bien.. emploie celle-là. Où est le pb ?

des cas, 6 secondes dans le pire des cas. Bon j'ai même été jusqu'à 30
secondes car je faisais les regcomp/regfree dans la boucle alors qu'il
suffit de le faire une fois. Après tout est relatif...





--
christophe. [ou pas]
Avatar
espie
In article <4c53e956$0$10221$,
xtof pernod wrote:
Je dirais que c'est au programmeur. L'appli, elle, est programmée pour en
avoir rien à foutre. Ce qu'elle fait avec le plus grand bonheur..

mais a l'utilisateur. Un utilisateur



Euh.. Si tu peux parler à tes utilisateurs de perm. en octal ,
pas de doute, c'est de la balle^W^W^W. l'idéal.
Mais c'est plutôt rare dans le cas général...



J'ai pas besoin de lui en parler, c'est la partie "generale" du systeme
qui positionne les choses pour lui. Si un systeme Unix loggue tes
utilisateurs avec un umask 0 par defaut, il est completement buggue.


normal aura 022 comme umask. S'il a autre chose, c'est son probleme, et
c'est pas a ton programme de decider a sa place !



Bon.. On va peut-être pas trétrasectionner pour 022 euroctals, si ?
Ou alors au comptoir. fu2 pré-postionné, il y a plein de gens inspirés.



Je risque pas de te suivre la-bas, ca fait jamais qu'une 2e erreur, hein,
Les API dont on parle sont POSIX, donc *Unix* en general.

Et c'est pas du tout du coupage de cheveu en 4: le mode le plus classique
d'ouvrir du fichier en ecriture avec open(2), c'est 0666. C'est ce qui est
utilise dans tous les programmes par defaut. C'est ce qui est documente
partout (entre autres, dans Stevens ou Rifflet), et il y a d'excellentes
raisons a ca.

On est dans un groupe technique, on y parle de choses techniques. Tu
ecris des trucs qui sont des erreurs graves de programmation systeme.
J'essaie de t'expliquer pourquoi gentiement, mais tu ne veux pas comprendre.

Je le redis donc avec plus de conviction: ouvrir un fichier en ecriture dans
un programme Unix, ca se fait le plus souvent avec 0666. Utiliser autre
chose sans raison particuliere *liee au programme* est une erreur, provenant
le plus souvent d'une profonde incomprehension des regles et usages lies
a open(2) et umask(2).
Avatar
Samuel DEVULDER
Benoit Izac a écrit :
Bonjour,

le 31/07/2010 à 00:19, xtof pernod a écrit dans le message
<4c535001$0$10191$ :

Je vois bien. Le pb a pourtant pas l'air compliqué, je pense que 10 lignes
de codes devraient suffire, à moins que j'ai loupé un truc.

Faut dire aussi que les infos arrivent un peu au compte-goutte..



Faut pas exagérer non plus. Je reconnais que je me suis viandé avec
fread(), ce qui a provoqué plus de réponses concernant read/open que sur
le problème en lui-même.



Oui c'est l'un des problèmes que je constate aussi avec les piliers du
groupes (les "experts" pour résumer). Ils se focalisent sur des détails
sans comprendre le (ou sans vouloir répondre au) sens de la question.
Cela crée tout de suite des fils à rallonge (vive les querelles
d'experts) qui ne causent même plus du problème d'origine et qui sont
complètement imbuvables. C'est sur que pinailler sur un point technique
qui n'est pas le fond du problème est très facile et montre sa profond
compétences des différents aspects et entremêlement des standards, et
aspects systèmes (bravo aux experts!) mais c'est parfois hors de propos
et n'aide en rien le posteur originel.

Exemple typique au lieu de répondre à la question "est-ce qu'on peut
simplifier l'API de la fonction?" , ca part sur des dérives au sujet de
open et ses includes et autres 0666 (number of the beast) complètement
hors de sujet.

Beaucoup oublient que parfois un bout de code ecrit sur le NG n'est pas
le code reel mais qu'il n'est la que pour fixer les idées. Dans la vraie
vie les codes C sont beaucoup plus gros que les 10-15 lignes qu'on ne
peut décemment poster sur une newsgroup et il est normal voir obligé de
shunter des détails important pour l'appli complète (includes par
exemple) mais pas pour le pb spécifique qui coince.

De toute façon à voir les fils les plus long, donc les points les plus
typiquement discutés sur le NG j'aurais l'impression que faire du C
revient super souvent à lire des trucs via le flux standard en
environnement unix et effectuer quelques traitement sur les chaines de
caractères. Heureusement que la programmation (et ses bugs) est beaucoup
plus riche et intéressante que cela avec pleins d'api et de traitements
variés. Du reste, quand on prend du recul, le truc qui coince sur des
petits exemples est souvent à trouver dans la logique du prog (var pas
initialisée, break mal placé, etc) que de condition d'execution rares
telles que "fread() n'a pas tout lu",ou "malloc a echoué", il te manque
tel include en environnement XYZ, etc.

Oulala, je sens que ce que j'écris peut être mal interpréter si on ne
prend pas de recul et qu'on reste attaché aux détails. Aussi je
m'empresse de préciser que parfois oui il est normal d'avoir l'avis des
experts sur les points techniques quand c'est l'endroit qui pose
problème. Mais de là à voir des querelles d'expert sur chaque fil, il y
a de la marge.

Il faudrait trouver un truc, une notation, pour indiquer qu'un bout de
code est a prendre oui ou non au pied de la lettre auquel cas les
experts peuvent s'en donner à coeur joie. Mais si la notation indique
que c'est un exemple pour fixer les idées, alors de grâce qu'ils passent
outre les simplifications et abus dans le code et se concentrent sur le
pb qui coince vraiment.

sam.
1 2 3 4 5