Discussion :

[gl]

ça sert en particulier quand on fait un fgets, où la ligne lue comporte un '\n' (éventuellment un '\r').

Comme ça on écrase systématiquement le '\n'.

Utiliser de cette manière c'est assez dangereux. En effet, on élimine ainsi systématiquement le dernier caractère de la chaîne même lorsque ce dernier n'est pas un \n, ce qui est le cas si la lecture s'arrête car la taille maximale est atteinte.

Bref utiliser un tel code pour éliminer le \n dans une chaîne de caractère lue par fgets() va poser un problème (perte d'un caractère) dans certains cas.

[souviron34]

Utiliser de cette manière c'est assez dangereux. En effet, on élimine ainsi systématiquement le dernier caractère de la chaîne même lorsque ce dernier n'est pas un \n, ce qui est le cas si la lecture s'arrête car la taille maximale est atteinte.
Bref utiliser un tel code pour éliminer le \n dans une chaîne de caractère lue par fgets() va poser un problème (perte d'un caractère) dans certains cas.

encore une fois tout dépend de l'usage...

Si tu lis un fichier formaté dont tu sais pertinneent que les lignes font 80 et que tu lis dans un buffer de 3000, où est le problème ?

Mainteant, je suis bien d'accord que le mieux est de faire un "strchr ou un if..

Mais cela n'empêche pas que l'on peut faire un if avec le trlen()-1, et donc remplacer également.

Quant à ces arguments de tailles max, franchement je commence un peu à mé demander si mêê en programmation on est pas passé à la "political correctness"..

La moindre des choses dans un code est de savoir ce qu'on fait, et ce qu'on traite..

Si on ne le sait pas, on prend alors les mesures qu'il faut, et ne pas utiliser strlen(-1) à cause du possible dépassement en est une.

Mais dans le cas contraire, ce qui est la majorité des cas de lecture de fichiers, franchement, je trouve ça plus qu'éxagéré...

[Melem]

Quant à ces arguments de tailles max, franchement je commence un peu à mé demander si mêê en programmation on est pas passé à la "political correctness".

Objectivement on pourrait interpréter cela comme quoi tu remettais en question l'importance des arguments de taille max dans les fonctions de lecture. Bien entendu, ce n'est pas ce que tu voulais dire mais alors j'aimerais bien savoir ce que tu voulais dire par là, parce que c'est vraiment pas clair pour moi.

La moindre des choses dans un code est de savoir ce qu'on fait, et ce qu'on traite..

Si on ne le sait pas, on prend alors les mesures qu'il faut, et ne pas utiliser strlen(-1) à cause du possible dépassement en est une.

Mais dans le cas contraire, ce qui est la majorité des cas de lecture de fichiers, franchement, je trouve ça plus qu'éxagéré...

Je trouve que c'est toi qui exagères un peu. Comment oses-tu dire que dans la majorité des cas de lecture de fichier, il est inutile de vérifier la taille des données lues. A part dans des formats très perso, utilisées dans des projets très particuliers, dans des circonstances très particulières, je ne connais pas trop de formats de fichier basés sur texte dans lesquels la taille d'une ligne est fixe. Tu peux nous en donner quelques exemples ?

[souviron34]

Objectivement on pourrait interpréter cela comme quoi tu remettais en question l'importance des arguments de taille max dans les fonctions de lecture. Bien entendu, ce n'est pas ce que tu voulais dire mais alors j'aimerais bien savoir ce que tu voulais dire par là, parce que c'est vraiment pas clair pour moi.

Je trouve que c'est toi qui exagères un peu. Comment oses-tu dire que dans la majorité des cas de lecture de fichier, il est inutile de vérifier la taille des données lues. A part dans des formats très perso, utilisées dans des projets très particuliers, dans des circonstances très particulières, je ne connais pas trop de formats de fichier basés sur texte dans lesquels la taille d'une ligne est fixe. Tu peux nous en donner quelques exemples ?

En 25 ans pratiquement tous les fichiers sur lesquels j'ai eu à travailler... Fichiers de préférences, dictionnaires, fichiers de coordonnées, fichiers de données, fichiers temporaires, sorties de modèles numériques, images, films, etc etc...




C'est au contraire l'exception ceux dont on ne connait pas la taille..



Baser donc une attitude sur une exception plutôt que la norme me semble être du domaine du fameux "principe de précaution" si à la mode...


Alors peut-être que vous avez des exemples concrets et suffisamment pléthoriques pour le justifier. Personnellement je n'en connais pas, ou si peu qu'ils ne valent pas le coup d'en faire une règle..


Quant à la l'importance des arguments de taille max, je suis également empli de .. doute, pour ne pas dire plus..

[Melem]

En 25 ans pratiquement tous les fichiers sur lesquels j'ai eu à travailler...

Je ne dis absolument pas que les fichiers texte avec lignes de taille fixe sont quasi inexistants, moi aussi j'ai déjà eu à les utiliser, mais les formats les plus diffusés et que presque tout le monde rencontre tous les jours ne le sont pas : fichiers de texte simple (.txt), fichiers de journalisation (.txt, .log), fichiers de configuration (.conf, .ini, etc.), fichiers de données (.txt, .csv, .xml), etc. Et même pour les formats que tu as cités, les lignes ne sont de mêmes tailles que dans des projets particuliers (dans combien de cas (de projet) par exemple les lignes d'un dictionnaire sont de mêmes tailles et dans combien de cas ne le sont-elles pas ?), certains étant même rarement des fichiers texte (films en txt ? ...). On parlait bien de fichiers texte hein ? Parce que si tu fais mêler aussi les fichiers binaires la notion de ligne elle-même n'aurait aucun sens.

Quant à la l'importance des arguments de taille max, je suis également empli de .. doute, pour ne pas dire plus..

C'est important lorsqu'on ne connaît pas d'avance la taille de la ligne qu'on va lire. Mais comme tu dis que tu travailles rarement sur de tels fichiers, je peux croire que tu peux effectivement t'en passer.

[souviron34]

Je ne dis absolument pas que les fichiers texte avec lignes de taille fixe sont quasi inexistants, moi aussi j'ai déjà eu à les utiliser, mais les formats les plus diffusés et que presque tout le monde rencontre tous les jours ne le sont pas : fichiers de texte simple (.txt), fichiers de journalisation (.txt, .log), fichiers de configuration (.conf, .ini, etc.), fichiers de données (.txt, .csv, .xml), etc. Et même pour les formats que tu as cités, les lignes ne sont de mêmes tailles que dans des projets particuliers (dans combien de cas (de projet) par exemple les lignes d'un dictionnaire sont de mêmes tailles et dans combien de cas ne le sont-elles pas ?)

Pour tous les exemples que tu donnes, normalement on a une spécification des fichiers.

Et donc on sait qu'est-ce qu'il a dedans.

Que ce soit fichiers de journalisation, de log, de conf, de ini, de données, etc, y compris un dictionnaire, tu as quelque part la doc du format.

Donc quand tu fais le programme qui lit, tu sais ce que tu vas lire..


Là on n'est pas en tain de faire des exercices d'écoles.


On est dans la vie professionnelle. On donne des conseils de professionnels à des professionnels ou des futurs professionnels.

On se doit donc de préciser que dans la quai-totalité des cas rencontrés professionnellement, la lecture d'un fichier texte se fait parce que l'on connaît son format (et si l'on n'a pas de spec, on en fait un dump pour savoir comment il est).

Je ré-itère donc que je n'ai jamais eu à rencontrer de fichier que je devais lire et dont je ne connaissais pas un majorant de la taille de ligne...

[Melem]

Pour tous les exemples que tu donnes, normalement on a une spécification des fichiers.

Et donc on sait qu'est-ce qu'il a dedans.

Que ce soit fichiers de journalisation, de log, de conf, de ini, de données, etc, y compris un dictionnaire, tu as quelque part la doc du format.

Donc quand tu fais le programme qui lit, tu sais ce que tu vas lire..


Là on n'est pas en tain de faire des exercices d'écoles.


On est dans la vie professionnelle. On donne des conseils de professionnels à des professionnels ou des futurs professionnels.

On se doit donc de préciser que dans la quai-totalité des cas rencontrés professionnellement, la lecture d'un fichier texte se fait parce que l'on connaît son format (et si l'on n'a pas de spec, on en fait un dump pour savoir comment il est).

Je ré-itère donc que je n'ai jamais eu à rencontrer de fichier que je devais lire et dont je ne connaissais pas un majorant de la taille de ligne...

OK. Je sais que tu n'as pas que ça à faire, donc je comprendrai si tu ne veux pas me répondre, mais ce serait vraiment intéressant si tu pouvais écrire ce tout petit programme pour qu'on soit vraiment convaincu.

On a un fichier texte dans la structure est la suivante :

Code :

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

1
2
<Nom d'un auteur>
<Citation>

Par exemple :

Code :

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

1
2
René Descartes
Je pense donc je suis.

Pourrais-tu écrire une fonction simplified_fgets(FILE * f, char * line) et l'utiliser dans un programme qui affiche la première ligne d'un tel fichier ?
Exemple d'exécution :

Code :

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

1
2
Fichier : je-pense.txt
Auteur : René Descartes

[souviron34]

non je ne répondrais pas..


Pas par manque de temps, simplement parce que je ne peux répondre à UN cas paticulier, qui a l'air de vous passionner, mais ne fait pas partie de la majorité des programmes C.


La reconnaissance et stockage de texte libre est presque exclusivement associée aux moteurs de recherche.

Peut-être que c'est ce sur quoi on vous fait travailler en fac ou à l'école.


Mais ce n'est qu'une infîme partie des applications de lecture de fichiers texte.

Donc je ne vois aucunement le besoin de répondre à ce style de choses..



Mais de toutes façons, je ne connais pas (un seul exemple : Edgar Allan Poe, une seule nouvelle) de phrases faisant plus d'une page.

Une page = 66 lignes = 66 * 80 = 5280

Admettons 100 pages max (un chapitre de 100 pages fait d'une seule phrase me semble plus que sûr...) = 528 000

Donc une allocation d'une ligne de 528 001 char me semblerait conforme..

[gl]

Pour tous les exemples que tu donnes, normalement on a une spécification des fichiers.

Et donc on sait qu'est-ce qu'il a dedans.

Que ce soit fichiers de journalisation, de log, de conf, de ini, de données, etc, y compris un dictionnaire, tu as quelque part la doc du format.

Si ce n'est que

• Pour les fichiers de conf et les fichiers ini, il y a une grande chance qu'ils soient à un moment donné ou à un autre modifié par un être qui peut ne pas respecter ce format (simple erreur de saisie, volonté de nuire ou autre) et qu'il est dommage de planter violemment dans ce cas de figure alors qu'il est possible de réagir correctement ou d'afficher un message de diagnostique clair et précis.
• Quant au fichier de log, si tu as la main sur ce qui les génère, oui il est raisonnable de supposer que le format sera respecté. Dans les cas contraire, cela me semble déjà plus discutable.
• Et je ne parle même pas de récupérer des entrées utilisateurs.

Donc quand tu fais le programme qui lit, tu sais ce que tu vas lire..

Dans un monde parfait, oui. Mais malheureusement, on est [1] rarement dans un cas parfait.

On se doit donc de préciser que dans la quai-totalité des cas rencontrés professionnellement, la lecture d'un fichier texte se fait parce que l'on connaît son format (et si l'on n'a pas de spec, on en fait un dump pour savoir comment il est).

Je ré-itère donc que je n'ai jamais eu à rencontrer de fichier que je devais lire et dont je ne connaissais pas un majorant de la taille de ligne...

Ben justement, non.

D'une part, je n'ai pas forcément toujours un majorant de la taille de la ligne (même si c'est un cas plutôt rare et que dans ces cas, je n'ai pas eu à me préoccuper de la présence ou non de \n).
Mais surtout, dans la très grande majorité des cas, j'ai effectivement un majorant "théorique" (ainsi qu'un format précis du fichier) mais je n'ai pas la garanti à 100% que le format sera respecté à la lettre (bug d'un autre programme, erreur de saisie, corruption de donnée, volonté de nuire, etc.) et il n'est pas envisageable de planter violemment en cas d'erreur. Donc je m'adapte et je vérifie mes entrées [2].





[1] Enfin je suis. Il est possible que tu ais plus de chance que moi à ce niveau. Au passage, cette différence de vécu est sans doute une des principales raisons des différences de point de vue rencontré dans ces forum (et ailleurs), chacun ayant tendance à répondre en fonction de ses contraintes et expériences, qui différent d'un membre à l'autre.

[2] Dans les cas où le respect du format est garanti ou où il est admissible de partir en sucette, je me permet effectivement d'être plus beaucoup plus souple dans les contrôles. Mais, chez moi, ces cas sont plus l'exception que la règle.

[souviron34]

même sans aller jusqu'aux limites donnés par mon exemple ci-dessus, et dans un logiciel "normal", je ne vois pas en quoi il y aurait "volonté de nuire"

Encore une fois, ne pas prendre l'exception pour la généralité..


Une ligne de 10000 char sevrait amplement suffire pour l'écasante majorité des cas.

Encore une fois, je ne suis pas contre le fait de prendre des précautions. JE conteste simplement le fait que cela justifie une règle, alors que c'est de mon point de vue plutôt l'exception...



PS: nous ne devons effectivement pas vivre dans le même monde...

Même les cas que j'ai eu où il était possible de modifier le fichier à la main, il est sain de pouvoir dire que l'éditeur / administrateur a effectué une erreur, et de ne pas laisser passer un fichier corrompu...

[souviron34]

J'ajouterais qu'un fichier de log est créé par un programme. Il y a donc un format associé. Même si on n'a pas la doc sous la main, on peut en déduire le format (ce qu'on doit faire si on veut pouvoir l'exploiter de toutes façons).

Un fichier de conf et d'ini c'est pareil. Même manuellement éditable, il se doit d'y avoir des formattages..

[gl]

Encore une fois, ne pas prendre l'exception pour la généralité..

C'est justement ce que je fais. Être robuste est plutôt de l'ordre de la généralité alors qu'avoir une certitude sur le respect du format (ou pouvoir crasher violemment) c'est plutôt l'exception.

Une ligne de 10000 char sevrait amplement suffire pour l'écasante majorité des cas.

Malheureusement, je ne travaille pas dans des environnement où la RAM disponible se contente en Go ni sur des programmes qui n'ont qu'une ou deux lignes d'entrée à parser de temps en temps.
C'est peut être là aussi où se situe une importante différence entre nos domaines d'activités.

Encore une fois, je ne suis pas contre le fait de prendre des précautions. JE conteste simplement le fait que cela justifie une règle, alors que c'est de mon point de vue plutôt l'exception...

Dans mon domaine c'est plutôt la règle.

Même les cas que j'ai eu où il était possible de modifier le fichier à la main, il est sain de pouvoir dire que l'éditeur / administrateur a effectué une erreur, et de ne pas laisser passer un fichier corrompu...

Tout à fait, il est indispensable de pouvoir détecter l'erreur et de remonter l'information.
Mais justement, c'est bien en filtrant et analysant les fichiers que l'on peut effectuer cette détection, pas en acceptant n'importe quoi et en essayant de fonctionner avec.

[gl]

J'ajouterais qu'un fichier de log est créé par un programme. Il y a donc un format associé. Même si on n'a pas la doc sous la main, on peut en déduire le format (ce qu'on doit faire si on veut pouvoir l'exploiter de toutes façons).

Un fichier de conf et d'ini c'est pareil. Même manuellement éditable, il se doit d'y avoir des formattages..

Mais je ne conteste pas du tout qu'il y ait un format.

Le point avec lequel je ne suis pas d'accord, c'est de supposer que le format sera systématiquement respecté.

de part mon expérience ce n'est pas vrai. Et il faut bien soit le détecter et réagir en conséquence soit être résistant à cette entrée et continuer de fonctionner proprement. Et ce n'est pas en supposant que le format est forcément correct et en effectuant aucune vérification que l'on peut y parvenir.

PS : concernant le point selon lequel on peut déduire le format, cela a tout de même c'est limite. Il faut nécessairement avoir une échantillon représentatif couvrant tout le cas de figure possible et c'est généralement très compliqué à avoir de manière certaine.
Pour reprendre le cas des log, il est assez facile d'avoir des exemples couvrant les cas nominaux et les cas d'erreur les plus classiques, par contre les cas d'erreur exceptionnels rencontrés une fois tout les 10 ans c'est déjà moins certains de les avoir dans l'échantillon.

[souviron34]

bon, visiblement nous ne travaillons pas dans les mêmes domaines..


Mais enfin je trouve, que ce soit pour ça, pour le cast, et pour plusieurs autes choses (les strncpy et autres) que l'on fait du "principe de précaution" à outrance, pour un langage qui est à utilisr par des gens qui savent ce qu'ils font, et d'autre part pour des cas particuliers mais qu'on érige en règle générale..

[Melem]

Le strncpy est une autre histoire. Cette fonction n'a pas l'intention de "sécuriser" d'une quelconque manière strcpy, qui est, tu as raison, sécurisée du moment qu'on l'utilise bien. Mais ce n'est pas le cas de gets par exemple qui est un modèle parfait de trou de sécurité.

[souviron34]

oui mais là on parlait juste d'écrire ligne[strlen(ligne)-1] ..


Et comme tout le monde le sait, tout le monde utilise fgets

ce qui ne change rien à ce dont nous discutions...