j'utilise <ctime> dans mon prog mais la precision n'est pas au rendez
vous, plusieurs secondes sur une minute :-( n'y a t'il pas une autre api
plus precise.
"Bertrand Lenoir-Welter" a écrit dans le message de news: 432da987$0$7832$
Stan :
Donc, je ne peux pas penser que la majorité des utilisateurs de C ignorent l'existence des autres membres de la famille de strcpy.
strlcpy, je connaissais pas, y'a pas ça dans mon stdio.h. Ca fait quoi de plus ?
Compense les lacunes de strncpy, et là, ne me dit pas que tu ne connait pas cette dernière !
-- -Stan
Bertrand Lenoir-Welter
Stan :
Compense les lacunes de strncpy, et là, ne me dit pas que tu ne connait pas cette dernière !
Si, mais ça m'en dit pas plus. Si je comprends bien, strlcpy fait la même chose que strncpy moins les lacunes. Je me sers très peu de strncpy, mais je voudrais pas mourir idiot. Pouvez développer ?
Stan :
Compense les lacunes de strncpy, et là, ne me dit pas que tu ne connait pas
cette dernière !
Si, mais ça m'en dit pas plus. Si je comprends bien, strlcpy fait la
même chose que strncpy moins les lacunes. Je me sers très peu de
strncpy, mais je voudrais pas mourir idiot. Pouvez développer ?
Compense les lacunes de strncpy, et là, ne me dit pas que tu ne connait pas cette dernière !
Si, mais ça m'en dit pas plus. Si je comprends bien, strlcpy fait la même chose que strncpy moins les lacunes. Je me sers très peu de strncpy, mais je voudrais pas mourir idiot. Pouvez développer ?
Anthony Fleury
Bonsoir,
Stan :
Compense les lacunes de strncpy, et là, ne me dit pas que tu ne connait pas cette dernière !
Si, mais ça m'en dit pas plus. Si je comprends bien, strlcpy fait la même chose que strncpy moins les lacunes. Je me sers très peu de strncpy, mais je voudrais pas mourir idiot. Pouvez développer ?
Plus d'explications sont présentes dans ce document entre autre :
http://www.openbsd.org/papers/strlcpy-paper.ps
À noter aussi que strlcpy n'est pas standard en C, même si elle est maintenant disponible au moins sur les BSD (autre je ne sais pas).
-- Anthony Fleury
Bonsoir,
Stan :
Compense les lacunes de strncpy, et là, ne me dit pas que tu ne
connait pas cette dernière !
Si, mais ça m'en dit pas plus. Si je comprends bien, strlcpy fait la
même chose que strncpy moins les lacunes. Je me sers très peu de
strncpy, mais je voudrais pas mourir idiot. Pouvez développer ?
Plus d'explications sont présentes dans ce document entre autre :
http://www.openbsd.org/papers/strlcpy-paper.ps
À noter aussi que strlcpy n'est pas standard en C, même si elle est
maintenant disponible au moins sur les BSD (autre je ne sais pas).
Compense les lacunes de strncpy, et là, ne me dit pas que tu ne connait pas cette dernière !
Si, mais ça m'en dit pas plus. Si je comprends bien, strlcpy fait la même chose que strncpy moins les lacunes. Je me sers très peu de strncpy, mais je voudrais pas mourir idiot. Pouvez développer ?
Plus d'explications sont présentes dans ce document entre autre :
http://www.openbsd.org/papers/strlcpy-paper.ps
À noter aussi que strlcpy n'est pas standard en C, même si elle est maintenant disponible au moins sur les BSD (autre je ne sais pas).
-- Anthony Fleury
kanze
Stan ( remove the dots ) wrote:
"bernard tatin" a écrit dans le message de news: hqJWe.34648$
4) plein de gens connaissent strcpy mais ni strncpy ni strlcpy,
C'est un peu fantaisiste comme affirmation, non ?
Pas vraiment.
strcpy, c'est l'original. K&R s'en servait dans la première édition de "The C Programming Language". C'est la fonction de copie par excellence d'une chaîne (en C).
strncpy est assez ancien aussi. Je ne me rappelle plus, mais il se peut que K&R en parlait aussi. Et il fait partie de C90.
strlcpy n'existe pas, autant que je sache. Il ne fait pas partie de C90, ni de C99. C'est la première fois que j'en entends parler.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Stan ( remove the dots ) wrote:
"bernard tatin" <bernard.tatin@nospam.tele2.fr.invalid> a
écrit dans le message de news:
hqJWe.34648$hV3.14917@nntpserver.swip.net...
4) plein de gens connaissent strcpy mais ni strncpy ni strlcpy,
C'est un peu fantaisiste comme affirmation, non ?
Pas vraiment.
strcpy, c'est l'original. K&R s'en servait dans la première
édition de "The C Programming Language". C'est la fonction de
copie par excellence d'une chaîne (en C).
strncpy est assez ancien aussi. Je ne me rappelle plus, mais il
se peut que K&R en parlait aussi. Et il fait partie de C90.
strlcpy n'existe pas, autant que je sache. Il ne fait pas partie
de C90, ni de C99. C'est la première fois que j'en entends
parler.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
"bernard tatin" a écrit dans le message de news: hqJWe.34648$
4) plein de gens connaissent strcpy mais ni strncpy ni strlcpy,
C'est un peu fantaisiste comme affirmation, non ?
Pas vraiment.
strcpy, c'est l'original. K&R s'en servait dans la première édition de "The C Programming Language". C'est la fonction de copie par excellence d'une chaîne (en C).
strncpy est assez ancien aussi. Je ne me rappelle plus, mais il se peut que K&R en parlait aussi. Et il fait partie de C90.
strlcpy n'existe pas, autant que je sache. Il ne fait pas partie de C90, ni de C99. C'est la première fois que j'en entends parler.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Stan ( remove the dots ) wrote:
"Fabien LE LEZ" a écrit dans le message de news:
On Sun, 18 Sep 2005 13:29:17 +0200, "Stan" ( remove the dots )>:
4) plein de gens connaissent strcpy mais ni strncpy ni strlcpy,
C'est un peu fantaisiste comme affirmation, non ?
Pas forcément. Un programmeur C++ connaît strcpy (c'est de la culture générale) et peut ne pas connaître les deux autres. Mais c'est pas grave, vu qu'il n'utilise pas strcpy de toutes façons.
Si je relie cette allégation au point 2, je suppose que l'auteur parlait de programmeurs C; d'ailleurs le code cité en exemple appuierait cette hypothèse. Donc, je ne peux pas penser que la majorité des utilisateurs de C ignorent l'existence des autres membres de la famille de strcpy.
Si on connaît le C, même supérficiellement, on connaît strcpy() -- comme disait Fabien, même les programmeurs C++ le connaît. Si on connaît bien le C, on doit aussi connaître strncpy() ; elle fait partie de la norme, y compris la version C90, et était courant bien avant. En ce qui concerne strlcpy, en revanche, elle ne fait partie ni de C, ni de Posix, ni de Open System Unix. C'est donc une extension locale qui n'a rien à faire avec le C.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Stan ( remove the dots ) wrote:
"Fabien LE LEZ" <gramster@gramster.com> a écrit dans le
message de news: ojnqi1t8p6a3575eqfigag9ilnob9otgjk@4ax.com...
On Sun, 18 Sep 2005 13:29:17 +0200, "Stan"
<z.y.l.o.g@wanadoo.fr ( remove the dots )>:
4) plein de gens connaissent strcpy mais ni strncpy ni strlcpy,
C'est un peu fantaisiste comme affirmation, non ?
Pas forcément. Un programmeur C++ connaît strcpy (c'est de
la culture générale) et peut ne pas connaître les deux
autres. Mais c'est pas grave, vu qu'il n'utilise pas strcpy
de toutes façons.
Si je relie cette allégation au point 2, je suppose
que l'auteur parlait de programmeurs C;
d'ailleurs le code cité en exemple appuierait cette hypothèse.
Donc, je ne peux pas penser que la majorité des utilisateurs
de C ignorent l'existence des autres membres de la famille de
strcpy.
Si on connaît le C, même supérficiellement, on connaît
strcpy() -- comme disait Fabien, même les programmeurs C++ le
connaît. Si on connaît bien le C, on doit aussi connaître
strncpy() ; elle fait partie de la norme, y compris la version
C90, et était courant bien avant. En ce qui concerne strlcpy, en
revanche, elle ne fait partie ni de C, ni de Posix, ni de Open
System Unix. C'est donc une extension locale qui n'a rien à
faire avec le C.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
On Sun, 18 Sep 2005 13:29:17 +0200, "Stan" ( remove the dots )>:
4) plein de gens connaissent strcpy mais ni strncpy ni strlcpy,
C'est un peu fantaisiste comme affirmation, non ?
Pas forcément. Un programmeur C++ connaît strcpy (c'est de la culture générale) et peut ne pas connaître les deux autres. Mais c'est pas grave, vu qu'il n'utilise pas strcpy de toutes façons.
Si je relie cette allégation au point 2, je suppose que l'auteur parlait de programmeurs C; d'ailleurs le code cité en exemple appuierait cette hypothèse. Donc, je ne peux pas penser que la majorité des utilisateurs de C ignorent l'existence des autres membres de la famille de strcpy.
Si on connaît le C, même supérficiellement, on connaît strcpy() -- comme disait Fabien, même les programmeurs C++ le connaît. Si on connaît bien le C, on doit aussi connaître strncpy() ; elle fait partie de la norme, y compris la version C90, et était courant bien avant. En ce qui concerne strlcpy, en revanche, elle ne fait partie ni de C, ni de Posix, ni de Open System Unix. C'est donc une extension locale qui n'a rien à faire avec le C.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
kanze
Bertrand Lenoir-Welter wrote:
Stan :
Donc, je ne peux pas penser que la majorité des utilisateurs de C ignorent l'existence des autres membres de la famille de strcpy.
strlcpy, je connaissais pas,
Moi non plus.
y'a pas ça dans mon stdio.h.
Sans doute parce qu'il n'est pas standard. Ni en C90, ni en C99, ni en Posix, ni en Open System (l'Unix « officiel »).
Vaut mieux donc l'éviter, si tu veux que ton code soit portable.
Ca fait quoi de plus ?
Ça doit dépendre du système. En supposant qu'elle soit présente sur plus d'un système.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Bertrand Lenoir-Welter wrote:
Stan :
Donc, je ne peux pas penser que la majorité des utilisateurs
de C ignorent l'existence des autres membres de la famille
de strcpy.
strlcpy, je connaissais pas,
Moi non plus.
y'a pas ça dans mon stdio.h.
Sans doute parce qu'il n'est pas standard. Ni en C90, ni en C99,
ni en Posix, ni en Open System (l'Unix « officiel »).
Vaut mieux donc l'éviter, si tu veux que ton code soit portable.
Ca fait quoi de plus ?
Ça doit dépendre du système. En supposant qu'elle soit présente
sur plus d'un système.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Donc, je ne peux pas penser que la majorité des utilisateurs de C ignorent l'existence des autres membres de la famille de strcpy.
strlcpy, je connaissais pas,
Moi non plus.
y'a pas ça dans mon stdio.h.
Sans doute parce qu'il n'est pas standard. Ni en C90, ni en C99, ni en Posix, ni en Open System (l'Unix « officiel »).
Vaut mieux donc l'éviter, si tu veux que ton code soit portable.
Ca fait quoi de plus ?
Ça doit dépendre du système. En supposant qu'elle soit présente sur plus d'un système.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Richard Delorme
Bonsoir,
Stan :
Compense les lacunes de strncpy, et là, ne me dit pas que tu ne connait pas cette dernière !
Si, mais ça m'en dit pas plus. Si je comprends bien, strlcpy fait la même chose que strncpy moins les lacunes. Je me sers très peu de strncpy, mais je voudrais pas mourir idiot. Pouvez développer ?
Plus d'explications sont présentes dans ce document entre autre :
http://www.openbsd.org/papers/strlcpy-paper.ps
À noter aussi que strlcpy n'est pas standard en C, même si elle est maintenant disponible au moins sur les BSD (autre je ne sais pas).
Aussi chez BSD, Apple MacOS X (normal, c'est un BSD), Solaris, Linux, cygwin, etc.
-- Richard
Bonsoir,
Stan :
Compense les lacunes de strncpy, et là, ne me dit pas que tu ne
connait pas cette dernière !
Si, mais ça m'en dit pas plus. Si je comprends bien, strlcpy fait la
même chose que strncpy moins les lacunes. Je me sers très peu de
strncpy, mais je voudrais pas mourir idiot. Pouvez développer ?
Plus d'explications sont présentes dans ce document entre autre :
http://www.openbsd.org/papers/strlcpy-paper.ps
À noter aussi que strlcpy n'est pas standard en C, même si elle est
maintenant disponible au moins sur les BSD (autre je ne sais pas).
Aussi chez BSD, Apple MacOS X (normal, c'est un BSD), Solaris, Linux,
cygwin, etc.
Compense les lacunes de strncpy, et là, ne me dit pas que tu ne connait pas cette dernière !
Si, mais ça m'en dit pas plus. Si je comprends bien, strlcpy fait la même chose que strncpy moins les lacunes. Je me sers très peu de strncpy, mais je voudrais pas mourir idiot. Pouvez développer ?
Plus d'explications sont présentes dans ce document entre autre :
http://www.openbsd.org/papers/strlcpy-paper.ps
À noter aussi que strlcpy n'est pas standard en C, même si elle est maintenant disponible au moins sur les BSD (autre je ne sais pas).
Aussi chez BSD, Apple MacOS X (normal, c'est un BSD), Solaris, Linux, cygwin, etc.
-- Richard
Richard Delorme
En ce qui concerne strlcpy, en revanche, elle ne fait partie ni de C, ni de Posix, ni de Open System Unix. C'est donc une extension locale qui n'a rien à faire avec le C.
Non, et c'est bien dommage. Si l'on veut trouver un bug ou une faille de sécurité dans un programme en C, il suffit bien souvent de chercher s'il utilise strcpy/strncpy ou strcat/strncat qui ont toutes les chances d'être mal utilisés. Si l'on ne peut pas utiliser strlcpy, on peut aussi facilement le réimplémenter, où utiliser une implémentation libre de droit comme celle là : http://cbfalconer.home.att.net/download/strlcpy.zip
A noter qu'il y a une proposition pour ajouter des fonctions plus sûres dans la norme C0X du langage C, dont un strncpy_s : http://www.open-std.org/jtc1/sc22/open/n3838.pdf
-- Richard
En ce qui concerne strlcpy, en
revanche, elle ne fait partie ni de C, ni de Posix, ni de Open
System Unix. C'est donc une extension locale qui n'a rien à
faire avec le C.
Non, et c'est bien dommage. Si l'on veut trouver un bug ou une faille de
sécurité dans un programme en C, il suffit bien souvent de chercher s'il
utilise strcpy/strncpy ou strcat/strncat qui ont toutes les chances
d'être mal utilisés. Si l'on ne peut pas utiliser strlcpy, on peut aussi
facilement le réimplémenter, où utiliser une implémentation libre de
droit comme celle là :
http://cbfalconer.home.att.net/download/strlcpy.zip
A noter qu'il y a une proposition pour ajouter des fonctions plus sûres
dans la norme C0X du langage C, dont un strncpy_s :
http://www.open-std.org/jtc1/sc22/open/n3838.pdf
En ce qui concerne strlcpy, en revanche, elle ne fait partie ni de C, ni de Posix, ni de Open System Unix. C'est donc une extension locale qui n'a rien à faire avec le C.
Non, et c'est bien dommage. Si l'on veut trouver un bug ou une faille de sécurité dans un programme en C, il suffit bien souvent de chercher s'il utilise strcpy/strncpy ou strcat/strncat qui ont toutes les chances d'être mal utilisés. Si l'on ne peut pas utiliser strlcpy, on peut aussi facilement le réimplémenter, où utiliser une implémentation libre de droit comme celle là : http://cbfalconer.home.att.net/download/strlcpy.zip
A noter qu'il y a une proposition pour ajouter des fonctions plus sûres dans la norme C0X du langage C, dont un strncpy_s : http://www.open-std.org/jtc1/sc22/open/n3838.pdf
-- Richard
Stan
"kanze" a écrit dans le message de news:
connaît. Si on connaît bien le C, on doit aussi connaître strncpy() ; elle fait partie de la norme, y compris la version
C'est bien ce qui m'a fait réagir initialement.
C90, et était courant bien avant. En ce qui concerne strlcpy, en revanche, elle ne fait partie ni de C, ni de Posix, ni de Open System Unix. C'est donc une extension locale qui n'a rien à faire avec le C.
Quand j'évoquais les autres membres de la famille, je ne pensais pas à strlcpy, mais aux "cousins" comme strcat, et strncat. Et c'est comme si on m'affirmait que beaucoup connaissent strcat mais ignorent l'existence de strncat.
Il faut aussi savoir de quelle population on parle : qu'un étudiant n'est pas assez approfondi la chose, on peut le concevoir, mais que ce soit la majorité des programmeurs professionnels, je le répète, c'est fantaisiste.
-- -Stan
"kanze" <kanze@gabi-soft.fr> a écrit dans le message de news:
1127115723.409209.28570@z14g2000cwz.googlegroups.com...
connaît. Si on connaît bien le C, on doit aussi connaître
strncpy() ; elle fait partie de la norme, y compris la version
C'est bien ce qui m'a fait réagir initialement.
C90, et était courant bien avant. En ce qui concerne strlcpy, en
revanche, elle ne fait partie ni de C, ni de Posix, ni de Open
System Unix. C'est donc une extension locale qui n'a rien à
faire avec le C.
Quand j'évoquais les autres membres de la famille, je ne pensais
pas à strlcpy, mais aux "cousins" comme strcat, et strncat.
Et c'est comme si on m'affirmait que beaucoup connaissent strcat mais
ignorent l'existence de strncat.
Il faut aussi savoir de quelle population on parle :
qu'un étudiant n'est pas assez approfondi la chose,
on peut le concevoir, mais que ce soit la majorité des programmeurs
professionnels,
je le répète, c'est fantaisiste.
connaît. Si on connaît bien le C, on doit aussi connaître strncpy() ; elle fait partie de la norme, y compris la version
C'est bien ce qui m'a fait réagir initialement.
C90, et était courant bien avant. En ce qui concerne strlcpy, en revanche, elle ne fait partie ni de C, ni de Posix, ni de Open System Unix. C'est donc une extension locale qui n'a rien à faire avec le C.
Quand j'évoquais les autres membres de la famille, je ne pensais pas à strlcpy, mais aux "cousins" comme strcat, et strncat. Et c'est comme si on m'affirmait que beaucoup connaissent strcat mais ignorent l'existence de strncat.
Il faut aussi savoir de quelle population on parle : qu'un étudiant n'est pas assez approfondi la chose, on peut le concevoir, mais que ce soit la majorité des programmeurs professionnels, je le répète, c'est fantaisiste.
-- -Stan
bernard tatin
Stan wrote:
"bernard tatin" a écrit dans le message de news: hqJWe.34648$
4) plein de gens connaissent strcpy mais ni strncpy ni strlcpy,
C'est un peu fantaisiste comme affirmation, non ?
-- -Stan
Beaucoup de gens ici partent du principe que les utilisateurs de C/C++
sont des spécialistes de ces langages ou qu'ils vont le devenir. C'est faux. Il y a beaucoup d'utilisateurs de C et C++ qui ne sont pas des programmeurs mais qui n'ont pas le choix. En général, ces gens là n'aiment pas le C++ qu'ils trouvent trop lourd et trop compliqué. Je connais pas mal d'électronicien qui font de l'embarqué qui ne sont pas des spécialistes de C/C++. Ces gens là font du C++ souvent contraints et forcés sous Windows. Alors la STL, les string, iterateurs et autres flux, ils ignorent complètement. Le bout de code que j'ai fournit leur plaît bien, ils programment comme ça les bouts de tests qu'ils font pour vérifier que la RS232 ou le port ethernet de leur carte avec un 8051 ou un PIC fonctionne correctement. Effectivement, parfois ce code part chez un client, ce n'est pas toujours une bonne idée. Mais c'est comme ça et mon affirmation n'est pas fantaisiste dans le milieu où j'évolue.
Bernard.
Stan wrote:
"bernard tatin" <bernard.tatin@nospam.tele2.fr.invalid> a écrit dans le
message de news: hqJWe.34648$hV3.14917@nntpserver.swip.net...
4) plein de gens connaissent strcpy mais ni strncpy ni strlcpy,
C'est un peu fantaisiste comme affirmation, non ?
--
-Stan
Beaucoup de gens ici partent du principe que les utilisateurs de C/C++
sont des spécialistes de ces langages ou qu'ils vont le devenir. C'est
faux. Il y a beaucoup d'utilisateurs de C et C++ qui ne sont pas des
programmeurs mais qui n'ont pas le choix. En général, ces gens là
n'aiment pas le C++ qu'ils trouvent trop lourd et trop compliqué. Je
connais pas mal d'électronicien qui font de l'embarqué qui ne sont pas
des spécialistes de C/C++. Ces gens là font du C++ souvent contraints et
forcés sous Windows. Alors la STL, les string, iterateurs et autres
flux, ils ignorent complètement. Le bout de code que j'ai fournit leur
plaît bien, ils programment comme ça les bouts de tests qu'ils font pour
vérifier que la RS232 ou le port ethernet de leur carte avec un 8051 ou
un PIC fonctionne correctement. Effectivement, parfois ce code part chez
un client, ce n'est pas toujours une bonne idée. Mais c'est comme ça et
mon affirmation n'est pas fantaisiste dans le milieu où j'évolue.
"bernard tatin" a écrit dans le message de news: hqJWe.34648$
4) plein de gens connaissent strcpy mais ni strncpy ni strlcpy,
C'est un peu fantaisiste comme affirmation, non ?
-- -Stan
Beaucoup de gens ici partent du principe que les utilisateurs de C/C++
sont des spécialistes de ces langages ou qu'ils vont le devenir. C'est faux. Il y a beaucoup d'utilisateurs de C et C++ qui ne sont pas des programmeurs mais qui n'ont pas le choix. En général, ces gens là n'aiment pas le C++ qu'ils trouvent trop lourd et trop compliqué. Je connais pas mal d'électronicien qui font de l'embarqué qui ne sont pas des spécialistes de C/C++. Ces gens là font du C++ souvent contraints et forcés sous Windows. Alors la STL, les string, iterateurs et autres flux, ils ignorent complètement. Le bout de code que j'ai fournit leur plaît bien, ils programment comme ça les bouts de tests qu'ils font pour vérifier que la RS232 ou le port ethernet de leur carte avec un 8051 ou un PIC fonctionne correctement. Effectivement, parfois ce code part chez un client, ce n'est pas toujours une bonne idée. Mais c'est comme ça et mon affirmation n'est pas fantaisiste dans le milieu où j'évolue.