[SOS] Une ânerie pour bien commencer

[Brice Arnould]

Tout d'abord, bonjour et surtout merci à vous autres auteurs de cette série 
d'articles qui s'annonce formidable ^_^.

Voilà, j'ai moi même essayé de farfouiller dans le code de SOS (j'ai vue que 
klibc.c pour l'instant), et je crois que j'ai trouvée, au choix, une ou deux 
optimisations (inutiles) ou une faute de compréhension du code de ma part.
J'aurais voulu être fixé à ce sujet... désolé de vous déranger pour ça.

-Dans strlen:
========
unsigned int strlen(register const char *str)
{
  unsigned int retval = 0;
  while (*str++)
    retval++;
  return retval;
--------
Pourquoi avoir réservé un seul octet au lieu de quatre pour retval ? ça risque 
pas de faire en fait un strlen modulo 255 et des bugs pour les programmes 
utilisateurs ?
Et puis je croyais que les standards disaient que l'incrémention 
(contrairement aux autres assignations) pouvait être prioritaire sur le 
pointage, ce qui serait dangereux en cas de changement d'humeur des devs de 
GCC (mais ça m'étonne parce que dans ce cas la fonction n'aurait même pas 
marché je pense)).
========

-Je crois que "dst[len-1] = '\0'; " est superflu dans strzcpy (ça risque même 
de rajouter un problème si len == 0).
-Toujours dans strzcpy, pourquoi ne pas utiliser 32 bits pour stocker len ?

-Dans strzcat, est-ce que "char *res = dest;" ne risque pas de donner 
"*res==dest" (pointage prioritaire sur l'assignation) alors que le but serait 
"res==dest" ?

Enfin bon... j'arrête là parce que je pense que je dois vraiment vous casser 
les ******* -_^. Si par miracle, certains des trucs que j'ai cru trouver sont 
réellement des bugs mais que vous avez pas de temps à perdre, je me ferais 
une joie de chercher les bugs à votre place (dans klibc que j'arrive à 
comprendre et peut être ailleurs plus tard) et essayer de les corriger.

Merci encore pour votre excellent travail;
Brice

-- 
Doute du doute et tu croiras.
Enfin... je crois.