Petit rappel des faits (ce que j'ai compris de l'affaire) : à force d'auditer du code source C, Todd C. Miller et Theo de Raadt ont eu l'idée d'écrire des fonctions strlcpy() et strlcat() pour remplacer strcpy(), strncpy(), strcat() et strncat() (quand c'est opportun). strlcpy() et strlcat() ont divers avantages (ex: strlcpy garantit que la chaîne est terminée par un octet nul contrairement à strcat, strlcpy est plus rapide car ne remplit pas la fin par des zéros : en écrit un seul) et défauts (ex: strlcat calcule la taille de la source même si elle a été tronquée et est donc plus lent). En dehors du débat qualités/défauts, c'est surtout un bras de fer entre OpenBSD et les développeurs de la GNU libc : fierté, jalousie, ou que sais je.
De mon point de vue, strlcpy() est bien meilleur que strncpy() et plus sûr (limite les erreurs de programmation). Je ne trouve pas les arguments en défaveur de strlcpy() et strlcat() recevables, et je trouve ça dommage que finalement le choix soit « politique ».
Oui, on peut espérer que les développeurs d'EGLIBC soient plus « ouverts ». Il y a déjà eu des patchs acceptés dans EGLIBC qui risquent de ne jamais être accepté dans la GNU libc (ex: supporter un autre shell que bash). Ça rappelle effectivement les scissions Xfree86/X.org ou Sodipodi/Inkscape qui visaient elles aussi à se passer de développeurs peu coopératifs (cf. plutôt l'inverse de coopératif).
[^] # Re: cool
Posté par Victor STINNER (site web personnel) . En réponse au journal Debian migre de la GNU libc à EGLIBC. Évalué à 10.
De mon point de vue, strlcpy() est bien meilleur que strncpy() et plus sûr (limite les erreurs de programmation). Je ne trouve pas les arguments en défaveur de strlcpy() et strlcat() recevables, et je trouve ça dommage que finalement le choix soit « politique ».
Oui, on peut espérer que les développeurs d'EGLIBC soient plus « ouverts ». Il y a déjà eu des patchs acceptés dans EGLIBC qui risquent de ne jamais être accepté dans la GNU libc (ex: supporter un autre shell que bash). Ça rappelle effectivement les scissions Xfree86/X.org ou Sodipodi/Inkscape qui visaient elles aussi à se passer de développeurs peu coopératifs (cf. plutôt l'inverse de coopératif).