Le 01/09/2016 à 13:25, Patrick Lamaizière a écrit :
Yv : Bonjour,
C'est lequel le mieux ?
Celui qui est libre (je dis ça je dis rien)
Je trouve FreeBSD plus complet en logiciels dans les ports J'avais essayé OpenBSD il y a longtemps mais il était incomplet au niveau ports
JKB
Le Thu, 1 Sep 2016 15:52:52 +0200, Yv€s écrivait :
Le 01/09/2016 à 13:25, Patrick Lamaizière a écrit :
Yv : Bonjour,
C'est lequel le mieux ?
Celui qui est libre (je dis ça je dis rien)
Je trouve FreeBSD plus complet en logiciels dans les ports
FreeBSD serait bien s'il était POSIX. Enfin, jdçjdr.
J'avais essayé OpenBSD il y a longtemps mais il était incomplet au niveau ports
Quelle idée ? Je te conseille EdgeBSD. JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le 01/09/2016 à 13:25, Patrick Lamaizière a écrit :
Yv :
Bonjour,
C'est lequel le mieux ?
Celui qui est libre
(je dis ça je dis rien)
Je trouve FreeBSD plus complet en logiciels dans les ports
FreeBSD serait bien s'il était POSIX. Enfin, jdçjdr.
J'avais essayé OpenBSD il y a longtemps mais il était incomplet au
niveau ports
Quelle idée ? Je te conseille EdgeBSD.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Thu, 1 Sep 2016 15:52:52 +0200, Yv€s écrivait :
Le 01/09/2016 à 13:25, Patrick Lamaizière a écrit :
Yv : Bonjour,
C'est lequel le mieux ?
Celui qui est libre (je dis ça je dis rien)
Je trouve FreeBSD plus complet en logiciels dans les ports
FreeBSD serait bien s'il était POSIX. Enfin, jdçjdr.
J'avais essayé OpenBSD il y a longtemps mais il était incomplet au niveau ports
Quelle idée ? Je te conseille EdgeBSD. JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
espie
In article <nq9brh$evk$, Yvâ ¬s wrote:
Le 01/09/2016 à 13:25, Patrick Lamaizière a écrit :
Yv : Bonjour,
C'est lequel le mieux ?
Celui qui est libre (je dis ça je dis rien)
Je trouve FreeBSD plus complet en logiciels dans les ports J'avais essayé OpenBSD il y a longtemps mais il était incomplet au
^^^^^^^^^^^^^^^^
niveau ports
Je dis ca, je dis rien.
In article <nq9brh$evk$2@dont-email.me>, Yvâ ¬s <Yv@oorange.fr> wrote:
Le 01/09/2016 à 13:25, Patrick Lamaizière a écrit :
Yv :
Bonjour,
C'est lequel le mieux ?
Celui qui est libre
(je dis ça je dis rien)
Je trouve FreeBSD plus complet en logiciels dans les ports
J'avais essayé OpenBSD il y a longtemps mais il était incomplet au
Le 01/09/2016 à 13:25, Patrick Lamaizière a écrit :
Yv : Bonjour,
C'est lequel le mieux ?
Celui qui est libre (je dis ça je dis rien)
Je trouve FreeBSD plus complet en logiciels dans les ports J'avais essayé OpenBSD il y a longtemps mais il était incomplet au
^^^^^^^^^^^^^^^^
niveau ports
Je dis ca, je dis rien.
JKB
Le Thu, 1 Sep 2016 14:12:05 +0000 (UTC), Marc Espie écrivait :
In article <nq9brh$evk$, Yvâ ¬s wrote:
Le 01/09/2016 à 13:25, Patrick Lamaizière a écrit :
Yv : Bonjour,
C'est lequel le mieux ?
Celui qui est libre (je dis ça je dis rien)
Je trouve FreeBSD plus complet en logiciels dans les ports J'avais essayé OpenBSD il y a longtemps mais il était incomplet au
^^^^^^^^^^^^^^^^
niveau ports
Je dis ca, je dis rien.
En même temps, un OS qui t'engueule à l'édition des liens parce que tu as l'outrecuidance d'utiliser strcpy(), ça n'aide pas :-P JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le Thu, 1 Sep 2016 14:12:05 +0000 (UTC),
Marc Espie <espie@lain.home> écrivait :
In article <nq9brh$evk$2@dont-email.me>, Yvâ ¬s <Yv@oorange.fr> wrote:
Le 01/09/2016 à 13:25, Patrick Lamaizière a écrit :
Yv :
Bonjour,
C'est lequel le mieux ?
Celui qui est libre
(je dis ça je dis rien)
Je trouve FreeBSD plus complet en logiciels dans les ports
J'avais essayé OpenBSD il y a longtemps mais il était incomplet au
^^^^^^^^^^^^^^^^
niveau ports
Je dis ca, je dis rien.
En même temps, un OS qui t'engueule à l'édition des liens parce que
tu as l'outrecuidance d'utiliser strcpy(), ça n'aide pas :-P
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Thu, 1 Sep 2016 14:12:05 +0000 (UTC), Marc Espie écrivait :
In article <nq9brh$evk$, Yvâ ¬s wrote:
Le 01/09/2016 à 13:25, Patrick Lamaizière a écrit :
Yv : Bonjour,
C'est lequel le mieux ?
Celui qui est libre (je dis ça je dis rien)
Je trouve FreeBSD plus complet en logiciels dans les ports J'avais essayé OpenBSD il y a longtemps mais il était incomplet au
^^^^^^^^^^^^^^^^
niveau ports
Je dis ca, je dis rien.
En même temps, un OS qui t'engueule à l'édition des liens parce que tu as l'outrecuidance d'utiliser strcpy(), ça n'aide pas :-P JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Yv€s
Le 01/09/2016 à 15:57, JKB a écrit :
Le Thu, 1 Sep 2016 15:52:52 +0200, Yv€s écrivait :
Le 01/09/2016 à 13:25, Patrick Lamaizière a écrit :
Yv : Bonjour,
C'est lequel le mieux ?
Celui qui est libre (je dis ça je dis rien)
Je trouve FreeBSD plus complet en logiciels dans les ports
FreeBSD serait bien s'il était POSIX. Enfin, jdçjdr.
J'avais essayé OpenBSD il y a longtemps mais il était incomplet au niveau ports
Quelle idée ? Je te conseille EdgeBSD. JKB
<https://www.edgebsd.org/> ça commence mal,Firefox me bloque le site avec "La connexion n’est pas sécurisée"
Et pourtant, meme la glibc a fini par inclure strlcpy, hein. Apres, comme tu es bloque au 20e siecle, ca m'etonne pas que tu consideres encore strcpy comme une options raisonnable.
In article <slrnnsgdrs.8po.jkb@rayleigh.systella.fr>,
JKB <jkb@koenigsberg.invalid> wrote:
Et pourtant, meme la glibc a fini par inclure strlcpy, hein. Apres, comme tu es bloque au 20e siecle, ca m'etonne pas que tu consideres encore strcpy comme une options raisonnable.
JKB
Le Thu, 1 Sep 2016 14:19:22 +0000 (UTC), Marc Espie écrivait :
In article , JKB wrote:
Le Thu, 1 Sep 2016 14:12:05 +0000 (UTC), Marc Espie écrivait :
In article <nq9brh$evk$, Yvâ ¬s wrote:
Le 01/09/2016 à 13:25, Patrick Lamaizière a écrit :
Yv : Bonjour,
C'est lequel le mieux ?
Celui qui est libre (je dis ça je dis rien)
Je trouve FreeBSD plus complet en logiciels dans les ports J'avais essayé OpenBSD il y a longtemps mais il était incomplet au
^^^^^^^^^^^^^^^^
niveau ports
Je dis ca, je dis rien.
En même temps, un OS qui t'engueule à l'édition des liens parce que tu as l'outrecuidance d'utiliser strcpy(), ça n'aide pas :-P
Et pourtant, meme la glibc a fini par inclure strlcpy, hein. Apres, comme tu es bloque au 20e siecle, ca m'etonne pas que tu consideres encore strcpy comme une options raisonnable.
Sauf que... strcpy() et strncpy() sont standard contrairement à strlcpy(). Et que le compilo n'a pas à m'envoyer des messages d'insulte lorsque j'utilise une fonction standard. Il ne sais pas mieux que moi ce que je fais. Au passage, quitte à chercher à imposer quelque chose, il aurait été de bon ton de pousser les descripteurs de chaînes à l'instar de ce qu'il se fait sous OpenVMS. Parce que strlcpy(), c'est vraiment un truc qui a le cul assis entre deux chaises. JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le Thu, 1 Sep 2016 14:19:22 +0000 (UTC),
Marc Espie <espie@lain.home> écrivait :
In article <slrnnsgdrs.8po.jkb@rayleigh.systella.fr>,
JKB <jkb@koenigsberg.invalid> wrote:
Le Thu, 1 Sep 2016 14:12:05 +0000 (UTC),
Marc Espie <espie@lain.home> écrivait :
In article <nq9brh$evk$2@dont-email.me>, Yvâ ¬s <Yv@oorange.fr> wrote:
Le 01/09/2016 à 13:25, Patrick Lamaizière a écrit :
Yv :
Bonjour,
C'est lequel le mieux ?
Celui qui est libre
(je dis ça je dis rien)
Je trouve FreeBSD plus complet en logiciels dans les ports
J'avais essayé OpenBSD il y a longtemps mais il était incomplet au
^^^^^^^^^^^^^^^^
niveau ports
Je dis ca, je dis rien.
En même temps, un OS qui t'engueule à l'édition des liens parce que
tu as l'outrecuidance d'utiliser strcpy(), ça n'aide pas :-P
Et pourtant, meme la glibc a fini par inclure strlcpy, hein.
Apres, comme tu es bloque au 20e siecle, ca m'etonne pas que tu consideres
encore strcpy comme une options raisonnable.
Sauf que... strcpy() et strncpy() sont standard contrairement à
strlcpy(). Et que le compilo n'a pas à m'envoyer des messages d'insulte
lorsque j'utilise une fonction standard. Il ne sais pas mieux que
moi ce que je fais.
Au passage, quitte à chercher à imposer quelque chose, il aurait été
de bon ton de pousser les descripteurs de chaînes à l'instar de ce
qu'il se fait sous OpenVMS. Parce que strlcpy(), c'est vraiment un
truc qui a le cul assis entre deux chaises.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Thu, 1 Sep 2016 14:19:22 +0000 (UTC), Marc Espie écrivait :
In article , JKB wrote:
Le Thu, 1 Sep 2016 14:12:05 +0000 (UTC), Marc Espie écrivait :
In article <nq9brh$evk$, Yvâ ¬s wrote:
Le 01/09/2016 à 13:25, Patrick Lamaizière a écrit :
Yv : Bonjour,
C'est lequel le mieux ?
Celui qui est libre (je dis ça je dis rien)
Je trouve FreeBSD plus complet en logiciels dans les ports J'avais essayé OpenBSD il y a longtemps mais il était incomplet au
^^^^^^^^^^^^^^^^
niveau ports
Je dis ca, je dis rien.
En même temps, un OS qui t'engueule à l'édition des liens parce que tu as l'outrecuidance d'utiliser strcpy(), ça n'aide pas :-P
Et pourtant, meme la glibc a fini par inclure strlcpy, hein. Apres, comme tu es bloque au 20e siecle, ca m'etonne pas que tu consideres encore strcpy comme une options raisonnable.
Sauf que... strcpy() et strncpy() sont standard contrairement à strlcpy(). Et que le compilo n'a pas à m'envoyer des messages d'insulte lorsque j'utilise une fonction standard. Il ne sais pas mieux que moi ce que je fais. Au passage, quitte à chercher à imposer quelque chose, il aurait été de bon ton de pousser les descripteurs de chaînes à l'instar de ce qu'il se fait sous OpenVMS. Parce que strlcpy(), c'est vraiment un truc qui a le cul assis entre deux chaises. JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Et pourtant, meme la glibc a fini par inclure strlcpy, hein. Apres, comme tu es bloque au 20e siecle, ca m'etonne pas que tu consideres encore strcpy comme une options raisonnable.
Sauf que... strcpy() et strncpy() sont standard contrairement à strlcpy(). Et que le compilo n'a pas à m'envoyer des messages d'insulte
strncpy/strncat n'ont pas vocation a manipuler des chaines C (terminees par un zero), mais bien des buffers de taille fixe dans des structures (par exemple utmp)....
lorsque j'utilise une fonction standard. Il ne sais pas mieux que moi ce que je fais.
Suis pas sur que ca soit le cas... j'ai vu plein de gens qui "savaient ce qu'ils faisaient" ecrire du code de merde.
Ouais, sauf qu'entre une revolution impossible et un truc plus simple qui marche, on a tranche. Et accessoirement, a part des oiseaux rares dans ton genre, petit a petit, les gens adoptent strlcpy... ca prend du temps (>10 ans comme d'hab) mais c'est peu a peu en train de se faire. Evidemment, ca ne fera jamais plaisir a tout le monde, et ca ne me surprend pas que ca ne te plaise pas, vu tes objectifs antagonistes aux notres.
In article <slrnnsgim2.l7q.jkb@rayleigh.systella.fr>,
JKB <jkb@koenigsberg.invalid> wrote:
Et pourtant, meme la glibc a fini par inclure strlcpy, hein.
Apres, comme tu es bloque au 20e siecle, ca m'etonne pas que tu consideres
encore strcpy comme une options raisonnable.
Sauf que... strcpy() et strncpy() sont standard contrairement Ã
strlcpy(). Et que le compilo n'a pas à m'envoyer des messages d'insulte
strncpy/strncat n'ont pas vocation a manipuler des chaines C (terminees
par un zero), mais bien des buffers de taille fixe dans des structures (par
exemple utmp)....
lorsque j'utilise une fonction standard. Il ne sais pas mieux que
moi ce que je fais.
Suis pas sur que ca soit le cas... j'ai vu plein de gens qui "savaient ce
qu'ils faisaient" ecrire du code de merde.
Ouais, sauf qu'entre une revolution impossible et un truc plus simple qui
marche, on a tranche.
Et accessoirement, a part des oiseaux rares dans ton genre, petit a petit,
les gens adoptent strlcpy... ca prend du temps (>10 ans comme d'hab) mais
c'est peu a peu en train de se faire.
Evidemment, ca ne fera jamais plaisir a tout le monde, et ca ne me surprend
pas que ca ne te plaise pas, vu tes objectifs antagonistes aux notres.
Et pourtant, meme la glibc a fini par inclure strlcpy, hein. Apres, comme tu es bloque au 20e siecle, ca m'etonne pas que tu consideres encore strcpy comme une options raisonnable.
Sauf que... strcpy() et strncpy() sont standard contrairement à strlcpy(). Et que le compilo n'a pas à m'envoyer des messages d'insulte
strncpy/strncat n'ont pas vocation a manipuler des chaines C (terminees par un zero), mais bien des buffers de taille fixe dans des structures (par exemple utmp)....
lorsque j'utilise une fonction standard. Il ne sais pas mieux que moi ce que je fais.
Suis pas sur que ca soit le cas... j'ai vu plein de gens qui "savaient ce qu'ils faisaient" ecrire du code de merde.
Ouais, sauf qu'entre une revolution impossible et un truc plus simple qui marche, on a tranche. Et accessoirement, a part des oiseaux rares dans ton genre, petit a petit, les gens adoptent strlcpy... ca prend du temps (>10 ans comme d'hab) mais c'est peu a peu en train de se faire. Evidemment, ca ne fera jamais plaisir a tout le monde, et ca ne me surprend pas que ca ne te plaise pas, vu tes objectifs antagonistes aux notres.
JKB
Le Thu, 1 Sep 2016 15:52:38 +0000 (UTC), Marc Espie écrivait :
In article , JKB wrote:
Le Thu, 1 Sep 2016 14:19:22 +0000 (UTC), Marc Espie écrivait :
strncpy/strncat n'ont pas vocation a manipuler des chaines C (terminees par un zero), mais bien des buffers de taille fixe dans des structures (par exemple utmp)....
Entre autres, mais pas que.
lorsque j'utilise une fonction standard. Il ne sais pas mieux que moi ce que je fais.
Suis pas sur que ca soit le cas... j'ai vu plein de gens qui "savaient ce qu'ils faisaient" ecrire du code de merde.
Ça fait assez longtemps que je me fade du C pour à peu près savoir ce que je fais. Merci.
Au passage, quitte à chercher à imposer quelque chose, il aurait été de bon ton de pousser les descripteurs de chaînes à l'instar de ce qu'il se fait sous OpenVMS. Parce que strlcpy(), c'est vraiment un truc qui a le cul assis entre deux chaises.
Ouais, sauf qu'entre une revolution impossible et un truc plus simple qui marche, on a tranche. Et accessoirement, a part des oiseaux rares dans ton genre, petit a petit, les gens adoptent strlcpy... ca prend du temps (>10 ans comme d'hab) mais c'est peu a peu en train de se faire. Evidemment, ca ne fera jamais plaisir a tout le monde, et ca ne me surprend pas que ca ne te plaise pas, vu tes objectifs antagonistes aux notres.
Ça va mieux ? Par _construction_, le coup des chaînes terminées par un nul est une immense connerie. Le fait de remplacer des fonctions de la libc par une variante OpenBSDesque avalise juste cet état de fait et repousse le problème un peu plus loin. C'est d'ailleurs assez cohérent avec la stratégie de développement d'OpenBSD. Par ailleurs, j'ai ces fonctions dans mes NetBSD/FreeBSD, mais pas dans mes Solaris ou mes Linux (pourtant Debian/testing à jour). Je viens de tester pour les deux derniers à l'instant. Écrire du code qui ne tourne que sous quelques OS ne m'intéresse pas. C'est aussi idiot qu'utiliser asprintf(), pur produit de GNU. C'est efficace, ça évite de se poser des question, mais c'est particulièrement idiot en terme de portabilité. La chose réellement intelligente (mais pour cela, il faut certainement penser autre chose qu'Unix), cela aurait été de créer un type string comme un descripteur de chaîne en se retapant toutes les fonctions de manipulation de chaînes et de buffers de la libc. Je l'ai fait dans une autre vie et ça fonctionne très bien. Les nouvelles fonctions str*() peuvent alors envoyer directement un raise(SIGSEGV) dès que l'on sort du buffer alloué. Et lorsque tu n'as pas la bibliothèque qui va bien, un petit #define string char * te remet le code dans un état compilable. Au contraire, strlcpy() va renvoyer la longueur de la chaîne que la fonction a essayé de créer. Comme quasiment personne ne teste le retour des fonctions de la libc sauf à être contraint de le faire (et je suis chiant là-dessus avec les gens qui bossent avec moi), je vois les difficilement tester le retour des fonctions strl*(). Un bon assert() ou un raise() est bien plus efficace puisqu'en cas de dépassement, le code contient au moins une erreur d'accès mémoire. JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr
Le Thu, 1 Sep 2016 15:52:38 +0000 (UTC),
Marc Espie <espie@lain.home> écrivait :
In article <slrnnsgim2.l7q.jkb@rayleigh.systella.fr>,
JKB <jkb@koenigsberg.invalid> wrote:
Le Thu, 1 Sep 2016 14:19:22 +0000 (UTC),
Marc Espie <espie@lain.home> écrivait :
strncpy/strncat n'ont pas vocation a manipuler des chaines C (terminees
par un zero), mais bien des buffers de taille fixe dans des structures (par
exemple utmp)....
Entre autres, mais pas que.
lorsque j'utilise une fonction standard. Il ne sais pas mieux que
moi ce que je fais.
Suis pas sur que ca soit le cas... j'ai vu plein de gens qui "savaient ce
qu'ils faisaient" ecrire du code de merde.
Ça fait assez longtemps que je me fade du C pour à peu près savoir
ce que je fais. Merci.
Au passage, quitte à chercher à imposer quelque chose, il aurait été
de bon ton de pousser les descripteurs de chaînes à l'instar de ce
qu'il se fait sous OpenVMS. Parce que strlcpy(), c'est vraiment un
truc qui a le cul assis entre deux chaises.
Ouais, sauf qu'entre une revolution impossible et un truc plus simple qui
marche, on a tranche.
Et accessoirement, a part des oiseaux rares dans ton genre, petit a petit,
les gens adoptent strlcpy... ca prend du temps (>10 ans comme d'hab) mais
c'est peu a peu en train de se faire.
Evidemment, ca ne fera jamais plaisir a tout le monde, et ca ne me surprend
pas que ca ne te plaise pas, vu tes objectifs antagonistes aux notres.
Ça va mieux ?
Par _construction_, le coup des chaînes terminées par un nul est une
immense connerie. Le fait de remplacer des fonctions de la libc par
une variante OpenBSDesque avalise juste cet état de fait et repousse
le problème un peu plus loin. C'est d'ailleurs assez cohérent avec
la stratégie de développement d'OpenBSD.
Par ailleurs, j'ai ces fonctions dans mes NetBSD/FreeBSD, mais pas
dans mes Solaris ou mes Linux (pourtant Debian/testing à jour).
Je viens de tester pour les deux derniers à l'instant.
Écrire du code qui ne tourne que sous quelques OS ne m'intéresse
pas. C'est aussi idiot qu'utiliser asprintf(), pur produit de GNU.
C'est efficace, ça évite de se poser des question, mais c'est
particulièrement idiot en terme de portabilité.
La chose réellement intelligente (mais pour cela, il faut
certainement penser autre chose qu'Unix), cela aurait été de créer
un type string comme un descripteur de chaîne en se retapant toutes
les fonctions de manipulation de chaînes et de buffers de la libc.
Je l'ai fait dans une autre vie et ça fonctionne très bien. Les
nouvelles fonctions str*() peuvent alors envoyer directement un
raise(SIGSEGV) dès que l'on sort du buffer alloué. Et lorsque tu n'as pas
la bibliothèque qui va bien, un petit #define string char * te remet le
code dans un état compilable.
Au contraire, strlcpy() va renvoyer la longueur de la chaîne que la
fonction a essayé de créer. Comme quasiment personne ne teste le
retour des fonctions de la libc sauf à être contraint de le faire
(et je suis chiant là-dessus avec les gens qui bossent avec moi), je
vois les difficilement tester le retour des fonctions strl*(). Un
bon assert() ou un raise() est bien plus efficace puisqu'en cas de
dépassement, le code contient au moins une erreur d'accès mémoire.
JKB
--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr
=> http://loubardes.de-charybde-en-scylla.fr
Le Thu, 1 Sep 2016 15:52:38 +0000 (UTC), Marc Espie écrivait :
In article , JKB wrote:
Le Thu, 1 Sep 2016 14:19:22 +0000 (UTC), Marc Espie écrivait :
strncpy/strncat n'ont pas vocation a manipuler des chaines C (terminees par un zero), mais bien des buffers de taille fixe dans des structures (par exemple utmp)....
Entre autres, mais pas que.
lorsque j'utilise une fonction standard. Il ne sais pas mieux que moi ce que je fais.
Suis pas sur que ca soit le cas... j'ai vu plein de gens qui "savaient ce qu'ils faisaient" ecrire du code de merde.
Ça fait assez longtemps que je me fade du C pour à peu près savoir ce que je fais. Merci.
Au passage, quitte à chercher à imposer quelque chose, il aurait été de bon ton de pousser les descripteurs de chaînes à l'instar de ce qu'il se fait sous OpenVMS. Parce que strlcpy(), c'est vraiment un truc qui a le cul assis entre deux chaises.
Ouais, sauf qu'entre une revolution impossible et un truc plus simple qui marche, on a tranche. Et accessoirement, a part des oiseaux rares dans ton genre, petit a petit, les gens adoptent strlcpy... ca prend du temps (>10 ans comme d'hab) mais c'est peu a peu en train de se faire. Evidemment, ca ne fera jamais plaisir a tout le monde, et ca ne me surprend pas que ca ne te plaise pas, vu tes objectifs antagonistes aux notres.
Ça va mieux ? Par _construction_, le coup des chaînes terminées par un nul est une immense connerie. Le fait de remplacer des fonctions de la libc par une variante OpenBSDesque avalise juste cet état de fait et repousse le problème un peu plus loin. C'est d'ailleurs assez cohérent avec la stratégie de développement d'OpenBSD. Par ailleurs, j'ai ces fonctions dans mes NetBSD/FreeBSD, mais pas dans mes Solaris ou mes Linux (pourtant Debian/testing à jour). Je viens de tester pour les deux derniers à l'instant. Écrire du code qui ne tourne que sous quelques OS ne m'intéresse pas. C'est aussi idiot qu'utiliser asprintf(), pur produit de GNU. C'est efficace, ça évite de se poser des question, mais c'est particulièrement idiot en terme de portabilité. La chose réellement intelligente (mais pour cela, il faut certainement penser autre chose qu'Unix), cela aurait été de créer un type string comme un descripteur de chaîne en se retapant toutes les fonctions de manipulation de chaînes et de buffers de la libc. Je l'ai fait dans une autre vie et ça fonctionne très bien. Les nouvelles fonctions str*() peuvent alors envoyer directement un raise(SIGSEGV) dès que l'on sort du buffer alloué. Et lorsque tu n'as pas la bibliothèque qui va bien, un petit #define string char * te remet le code dans un état compilable. Au contraire, strlcpy() va renvoyer la longueur de la chaîne que la fonction a essayé de créer. Comme quasiment personne ne teste le retour des fonctions de la libc sauf à être contraint de le faire (et je suis chiant là-dessus avec les gens qui bossent avec moi), je vois les difficilement tester le retour des fonctions strl*(). Un bon assert() ou un raise() est bien plus efficace puisqu'en cas de dépassement, le code contient au moins une erreur d'accès mémoire. JKB -- Si votre demande me parvient sur carte perforée, je titiouaillerai très volontiers une réponse... => http://grincheux.de-charybde-en-scylla.fr => http://loubardes.de-charybde-en-scylla.fr