L'indication des tailles des tampons de lecture dans les fonctions est-elle importante ?

gl · 22/01/2010, 20h52

Envoyé par souviron34

ç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** · 23/01/2010, 02h10

Envoyé par gl

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** · 23/01/2010, 02h55

Envoyé par souviron34

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.

Envoyé par souviron34

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** · 23/01/2010, 12h54

Envoyé par Melem

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** · 23/01/2010, 13h31

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** · 23/01/2010, 14h11

Envoyé par Melem

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...

gl · 23/01/2010, 15h02

Envoyé par souviron34

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.

Envoyé par souviron34

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.

Envoyé par souviron34

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.

Envoyé par souviron34

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 · 23/01/2010, 15h10

Envoyé par 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..

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** · 23/01/2010, 16h34

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** · 23/01/2010, 18h27

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é.