PEBKAC #9776

Il y a quelques jours, on me fournit un programme à utiliser. Il doit générer une série de fichiers à partir d'un, dont je lui indique l'emplacement. Après quelques manipulations, je remarque qu'un bug survient lorsque l'adresse dudit fichier suit une certaine syntaxe. Qu'à cela ne tienne : comme la plupart des programmes scientifiques pointus, celui-ci est libre. Je m'en vais donc télécharger les sources pour trouver le problème exact afin de le signaler au concepteur. J'ai donc pu découvrir :

– Que la longueur du string contenant l'adresse du fichier était codé en dur. Nous avons donc en haut du main un joli #define BUFLEN 256, qui est par ailleurs également la longueur de tous les autres string du code.

– Que l'adresse du fichier ne pouvait pas contenir d'espaces (je n'ai pas encore trouvé exactement la source du problème, mais je soupçonne une fonction remove_extension d'en être la cause).

Je vais bien entendu envoyer un e-mail à l'auteur, mais en attendant… PEBKAC.

PEBKAC #9776 proposé par Audrey Azura le 16/04/2014 | 15 commentaires | 👍🏽 👎🏽 +117

Je m'abstiens pour le moment. En effet, je me demande de quand et pour quel système ce logiciel a été conçu. Si le programme d'origine est une antiquité des années 80 sous DOS, ce peut expliquer les limitations repérées.

Commentaire #137737 écrit par ygnobl le 16/04/2014 à 17h38 | 👍🏽 👎🏽

Programme scientifique pointu, qu'on utiliserait encore aujourd'hui ?
Ah !

Commentaire #137746 écrit par mini le 16/04/2014 à 17h46 | 👍🏽 👎🏽

Ce ne serait pas une excuse, mais une explication, car il peut rester des scories dans le source, ce qui serait plus excusable. Quand aux programmes "scientifiques" qui datent de l'an 40, je pourrais citer : LaTeX, GnuPlot, Maxima...

Commentaire #137750 écrit par ygnobl le 16/04/2014 à 17h54 | 👍🏽 👎🏽

Et dont on n'aurait pas fait de mises à jour, bien entendu.

La seule explication pour les limitations repérées, ce n'est pas l'âge du logiciel, c'est l'âge technologique du concepteur.

Commentaire #137752 écrit par mini le 16/04/2014 à 17h56 | 👍🏽 👎🏽

Idem, je ne vote pas.
Par contre, si c'est sous Windows, la limite à 256 caractères pour la longueur du fichier ne m'étonne guère : c'est la limite de l'explorateur Windows. Pour aller plus loin/plus profond, il faut créer une lettre lecteur qui pointe quelques dossiers plus bas pour que le chemin complet (avec le nom du fichier) fasse moins de 256 caractères.
Et j'imagine que le programme ne résous pas la lettre lecteur sur le point de montage (dans ce cas il faut que le chemin absolu fasse moins de 256 caractères, ce qui n'est pas contournable).
Mais effectivement, il y a des façons plus élégantes de le faire, encore que ça marche.

Commentaire #137755 écrit par Woofy le 16/04/2014 à 18h01 | 👍🏽 👎🏽

Un programme en C qui fixe la taille du buffer pour stocker une chaîne de caractères, c'est assez courant. Et oui, 256 est une valeur que tu vas retrouver. Sincèrement ça me semble peu commun de voir des noms de fichiers plus longs que cela, mais apparemment c'est ton cas. Pour la non gestion des espaces, par contre c'est de la paresse, clairement :)

Commentaire #137757 écrit par Paul le 16/04/2014 à 18h12 | 👍🏽 👎🏽

L'espace dans les dossiers et fichiers, c'est chiant comme la mort sur Unix et autres truc en 'x'.

Commentaire #137770 écrit par spidermoon le 16/04/2014 à 20h59 | 👍🏽 👎🏽

Bah, l'autocomplétion les échappe toute seule sur le tty. Pour la gestion dans le programme, je ne me suis jamais posé la question, je ne touche "sérieusement" qu'au shell (bash).

Commentaire #137786 écrit par ygnobl le 17/04/2014 à 01h15 | 👍🏽 👎🏽

Je ne peux qu'agréer avec Ygnobl sur ce point. J'ai déjà vu, dans des labos, des ordinateurs qu'on laisse volontairement sur windaube 98 parce qu'un des programmes utilisés a été codé pour ce système d'exploitation, et les concepteurs n'ont fait aucune mise à jour (pour leur donner une excuse, ce n'est pas non plus le travail principal des chercheurs que de coder).

Après, le logiciel en question est relativement récent (avec certitude, je ne peux que dire qu'il est de ce millénaire, mais je pense qu'il est même post-2005). Donc je ne pense pas que les problèmes cités viennent de là.

Commentaire #137790 écrit par Audrey Azura le 17/04/2014 à 04h34 | 👍🏽 👎🏽

@Woofy & Paul : Je ne savais pas pour la limite de caractère de l'explorateur windows. Merci de l'information ! Après quelques recherches, j'ai cependant pu constaté que mon problème ne venait pas de là, mais des espaces pas pris en compte.

De ce que j'ai pu comprendre, la console de windaube attends que, si ton chemin absolu contient des espaces, tu encadre ton chemin dans des guillemets. La correction que j'ai envoyé à la personne essayé (un peu maladroitement, je pense) de corriger ceci. Ca m'a aussi permis de voir que la gestion des espaces dans la console est toujours une sinécure, quelque soit ton système d'exploitation...

Commentaire #137791 écrit par Audrey Azura le 17/04/2014 à 04h42 | 👍🏽 👎🏽

Sous Linux c'est pareil, il faut passer par les guillemets dans ce cas là (vu que l'espace est le séparateur de paramètres dans ta commande)

Commentaire #137796 écrit par Limeila le 17/04/2014 à 08h54 | 👍🏽 👎🏽

Après les programmes scientifiques qui ne supportent pas les caractères spéciaux , c'est courant. Presque une norme .

Commentaire #137800 écrit par Partux le 17/04/2014 à 09h05 | 👍🏽 👎🏽

Il suffit pas de mettre des guillemets autour de ta chaine comme sous Windows ? Ca fait longtemps que j'ai pas utilisé de Linux.

Commentaire #137824 écrit par Acorah le 17/04/2014 à 10h20 | 👍🏽 👎🏽

Pas tout à fait : les séparateurs sont les caractères présents dans la variable $IFS, qui contient l'espace par défaut.

Extrait de man bash à propos de cette variable : The Internal Field Separator that is used for word splitting after expansion and to split lines into words with the read builtin command. The default value is ''<space><tab><newline>''.

Commentaire #137828 écrit par Acné le 17/04/2014 à 10h30 | 👍🏽 👎🏽

Sinon, tu peusx aussi les échapper avec des backslashs : ls Répertoire/ avec/ des/ espaces

Commentaire #137834 écrit par Asdf le 17/04/2014 à 11h01 | 👍🏽 👎🏽