http://www.courtesan.com/todd/papers/strlcpy.html
 
J'avais jamais tilté que strncpy remplissait de 0 le reste de la chaine
aïe. Déjà qu'strncpy est pas facile à utiliser, mais alors là ...

 
1) je ne suis pas certain que ce comportement soit standard (mais j'ai pas cherché quoi que ce soit qui traite de ce sujet)
2) je vois pas ce que ça change étant donné que, quand on manipule des chaînes, on s'arrête au premier '\0' rencontré et qu'on ne s'occupe pas du reste...

avec un t ?
 
1) si si, ça remplit de zero. strncpy écrit n caractères.
2) voir l'article. ça impacte sensiblement sur les performances. Tu le dis toi même, on ne s'occupe pas du reste, alors pourquoi ?

Yup, mais ni linux ni windows n'ont strlcpy il me semble.
Sous windows, c'est strsafe.h qui est recommendé pas Microsoft.
     http://msdn.microsoft.com/library/ [...] ctions.asp
 

ben t'as des choses comme la glib qui propose g_strlcpy

Tiens, je savais pas qu'elles avaient été intégrées dedans... (d'un autre côté, vu que Monsieur glibc n'en veut pas, mais veut bien d'un truc calembouresque comme strfry, il fallait bien que ça aille quelque part).

Je vais vérifier ça de suite...
 

Absolument aucune idée. Peut-être que c'est un truc comme "calloc" (que j'ai personnellement utilisé qu'une seule fois parce que j'avais la flemme d'initialiser).
Peut-être que c'est pour protéger le programmeur débile qui irait écraser accidentellement son '\0' => le suivant prend la relève
Peut-être que c'est pour éviter au programmeur qui veut rajouter un octet à sa chaîne de lui faire rajouter aussi le '\0' suivant.
Peut-être...
 

depuis quand le C ne fait plus confiance au programmeur ?

quand le buffer de destination est trop grand : perte de performance
quand le buffer de destination est trop petit : mettre le \0 soit meme ...
----> buchet
avec pas mal de ses collegues de <string.h>, également complice dans le satanisme  

http://leconjugueur.com/php/newcon [...] be=remplir

C'est le comportement standard.
 

 
Je parlais de vérifier le comportement de "strncpy", pas de vérifier la conjugaison du verbe "remplir". Mais j'apprécie le lien...
 
En effet, strncpy remplit le reste du buffer de '\0' (Emmanuel dit que c'est standard) alors que "strcpy" ne le fait pas. Pourquoi ? Boaf j'en sais rien (Emmanuel ?)
 
Un autre truc marrant de "strncpy", c'est que si la chaîne à copier est plus grande que la limite "n", la fonction ne met pas de '\0'.
Exemple: strncpy(dest, "1234567890", 5)
 
Voilà. C'était le quart-d'heure de "nos zauditeurs ont la parole"...
 
 
 

 
Depuis que certains programmeurs ont des idées tordues comme "je stocke un int dans un char" ou "je fais du memcpy pour affecter un char"    
 
Sans rire, maintenant que les machines sont 10000 fois plus rapides qu'en 1970, le C commence peut-être à vérifier qq trucs à la place du programmeur.
Et puis l'hypothèse du "cela permet de rajouter un caractère manuellement sans rajouter le '\0' suivant" est quand-même un petit-peu plausible...

Aucune idée. C'est pas moi qui ai écrit le C. Je me suis contenté un jour de télécharger la norme et d'en lire des bouts quand je suis sur le trône...
 
Un draft accessible très proche de C99 (pas strictement identique, mais seules les mouches soufffrent de ces différences...).  
 
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n869/
 
(Je suis scié. J'ai tapé 'n869' dans la fenetre de lien de Firefox, et il a trouvé ce répertoire directement en trois secondes...)

on me fait plus confiance ou quoi ?
 

tu voudrais que strcpy mettent des '\0' ?
 

tu viens de te reveiller là ?

sauf qu'on fait 10000 fois plus de choses avec.
 
Pas grand chose à voir, ca m'a fait bien marrer dans je sais plus qui (enfin si le créateur de C#) racontait qu'à l'époque de la limite des 640K sur pc, ils avaient des cycles de 1an, donc, après chaque version, ils recodaient tout depuis le départ

La confiance n'exclut pas le contrôle. Mais je voulais surtout savoir si ça le faisais aussi chez-moi (j'utilise plusieurs systèmes)...
 

Non, je disais juste que deux fonctions quasiment équivalentes ne font pas pareil. Je ne veux absolument rien et je suis déjà très heureux d'avoir mon '\0' final
 

C'était au cas où certains zauditeurs ne l'auraient pas su...

et si on brulait plutot le C pour ensuite s'enduire le corps de ses cendres avant d'aller forniquer comme des betes dans les bois ?

Par ce temps là, non merci !
 

http://www.microsoft.com/france/ms [...] 02004.html

Grillaid.

C'est très pratique en fait, si le dernier caractère de ton buffer de destination est un '\0', c'est que la copie n'a pas été interrompue par la taille de buffer trop réduite

 
Oui, surtout si tu utilises "strlen()" pour trouver le dernier octet  

...

Mauvaise langue. Je parle du dernier caractère de ton buffer. Vu que tu utilises strncpy, c'est que tu connais déjà quel est ce dernier caractère puisque tu passe la taille du buffer à la fonction.

 
Lol... j'avais compris mais c'était juste de l'humour...

je doute que le else s'affiche jamais ...

memset(dest, 'x', 1000);
 
et voilà...