readlink(2) et comportements des API

Samedi 1 octobre 2005 19:43 - Code

Ça fait plus de vingt ans qu'elle existe, qu'elle est documentée, la fonction readlink n'en pose pas moins encore problème à certains.

La faute au développeur ? Qui n'a pas lu la documentation ? Et qui s'est donc fait avoir non pas une mais deux fois ?

  1. en testant que le résultat était différent de zéro pour voir si elle avait réussi (foireux parce que quand elle échoue, c'est -1 qu'elle retourne, pas 0);
  2. en passant ensuite le buffer rempli avec le nom de fichier tel quel, c'est-à-dire sans "zéro de fin de chaîne", qui n'est pas placé par readlink (pour des raisons historiques, similaires à celles de strncpy).

La faute au développeur, probablement. Peut-être aussi d'avoir voulu développer en C alors qu'il n'aurait pas eu à se soucier de ces points dans un langage plus moderne (le premier étant communément traité avec des exceptions et le second étant traité par le fait d'avoir un type spécial pour les chaînes de caractères) (eh eh, après avoir écrit ça j'ai vérifié en Python et ça confirme la modernité de celui-ci :) ).

Mais ça pointe quand même sur un problème plus large, les développeurs s'attendent à certains comportements, en dévier amène des problèmes, même avec une imposante notice dans la documentation. Je n'ai pas connaissance d'une base rassemblant ces comportements attendus, ces common assumptions; c'est encore quelque chose qui s'acquiert uniquement avec l'expérience, c'est pourtant quelque chose indispensable si l'on veut créer une nouvelle API qui s'y tienne, maintenant que les raisons historiques de déviations genre readlink ne sont plus.