Deux choses me gênent dans la description de la fonction strcmp dans la
norme (C90 tout comme C99) :
1er point :
--------------------------------8<-----------------------------------
7.21.4 Comparison functions
1 The sign of a nonzero value returned by the comparison functions
memcmp, strcmp, and strncmp is determined by the sign of the difference
between the values of the first pair of characters (both interpreted as
unsigned char) that differ in the objects being compared.
-------------------------------->8-----------------------------------
Pourquoi employer l'expression "is determined" qui est assez vague
(pour moi, ici ça veut dire "est déterminé") ? Pourquoi ne pas dire
que les signes sont identiques (donc "coincides with" ou "matches" ou
"is identical to", etc) ?
2ème point :
--------------------------------8<-----------------------------------
7.21.4.2 p3 The strcmp function returns an integer greater than, equal
to, or less than zero, accordingly as the string pointed to by s1 is
greater than, equal to, or less than the string pointed to by s2.
-------------------------------->8-----------------------------------
Où dans la norme la notion de "chaîne plus grande qu'une autre" est-elle
définie ?
les fichiers utmp auraient dû être textuels comme tous les fichiers de log.
Sauf que utmp n'est _pas_ un fichier de log. Certains enregistrements sont modifiés 'en place', et donc doivent être d'une taille fixe pour permettre un accès plus ou moins direct. Ce qui explique son aspect un peu étrange et non textuel. Historiquement parlant...
-- On pourrait aussi se passer du 1 avec !0. "0"[!0] == ' '
--{ Charlie Gordon a plopé ceci: }--
les fichiers utmp auraient dû être textuels comme tous les fichiers de log.
Sauf que utmp n'est _pas_ un fichier de log. Certains enregistrements
sont modifiés 'en place', et donc doivent être d'une taille fixe pour
permettre un accès plus ou moins direct. Ce qui explique son aspect
un peu étrange et non textuel. Historiquement parlant...
--
On pourrait aussi se passer du 1 avec !0.
"0"[!0] == ' '
les fichiers utmp auraient dû être textuels comme tous les fichiers de log.
Sauf que utmp n'est _pas_ un fichier de log. Certains enregistrements sont modifiés 'en place', et donc doivent être d'une taille fixe pour permettre un accès plus ou moins direct. Ce qui explique son aspect un peu étrange et non textuel. Historiquement parlant...
-- On pourrait aussi se passer du 1 avec !0. "0"[!0] == ' '
Charlie Gordon
"Thierry B." a écrit dans le message de news:
--{ Charlie Gordon a plopé ceci: }--
les fichiers utmp auraient dû être textuels comme tous les fichiers de log.
Sauf que utmp n'est _pas_ un fichier de log. Certains enregistrements sont modifiés 'en place', et donc doivent être d'une taille fixe pour permettre un accès plus ou moins direct. Ce qui explique son aspect un peu étrange et non textuel. Historiquement parlant...
C'est plutot une faiblesse de ce fichier : un bete log des connexions et des deconnexions avec les infos de temps de connexion et autres statistiques au moment de la deconnexion aurait été largement suffisant et bien plus simple à parser par les outils textuels de l'epoque (awk...)
-- Chqrlie.
"Thierry B." <tth@prout.stex.invalid> a écrit dans le message de news:
os49n5-mdg.ln1@prout.stex...
--{ Charlie Gordon a plopé ceci: }--
les fichiers utmp auraient dû être textuels comme tous les fichiers de
log.
Sauf que utmp n'est _pas_ un fichier de log. Certains enregistrements
sont modifiés 'en place', et donc doivent être d'une taille fixe pour
permettre un accès plus ou moins direct. Ce qui explique son aspect
un peu étrange et non textuel. Historiquement parlant...
C'est plutot une faiblesse de ce fichier : un bete log des connexions et des
deconnexions avec les infos de temps de connexion et autres statistiques au
moment de la deconnexion aurait été largement suffisant et bien plus simple
à parser par les outils textuels de l'epoque (awk...)
les fichiers utmp auraient dû être textuels comme tous les fichiers de log.
Sauf que utmp n'est _pas_ un fichier de log. Certains enregistrements sont modifiés 'en place', et donc doivent être d'une taille fixe pour permettre un accès plus ou moins direct. Ce qui explique son aspect un peu étrange et non textuel. Historiquement parlant...
C'est plutot une faiblesse de ce fichier : un bete log des connexions et des deconnexions avec les infos de temps de connexion et autres statistiques au moment de la deconnexion aurait été largement suffisant et bien plus simple à parser par les outils textuels de l'epoque (awk...)
-- Chqrlie.
Charlie Gordon
"Marc Espie" a écrit dans le message de news: g7sa00$jdh$
In article <g7s4bc$c7a$, Charlie Gordon wrote:
Quant à appeler strncpy une fonction qui ne traite *pas* des chaines de caractères, c'est une erreur de nommage.
Ca, je suis d'accord.
Pour les cas que tu cites, une périphrase avec memset et memcpy est très simple, lisible et efficace.
Et le code avec strncpy est extremement court, certes un peu bizarre, mais le format qui va avec l'est aussi (et c'est un peu tard pour le changer).
Le code est court, et les librairies (esp glibc) font des efforts navrants pour optimiser en ligne, voire en assembleur, les appels à strncpy, au point d'y introduire des bugs (newlib).
Pour le reste, strncpy n'est pratiquement jamais la bonne solution, et trop souvent une source de bugs.
Totalement d'accord.
Mentionner cette fonction dans un tutoriel est une hérésie : le débutant n'a aucune chance de comprendre la sémantique tordue de cette saloperie, surtout s'il cherche à l'intuiter.
Egalement.
Donc : NE JAMAIS UTILISER LA FONCTION strncpy.
Oui, conseil a la Knuth. A suivre presque toujours, sauf lorsqu'on est dans le cas de figure pre-cite et qu'on sait exactement ce qu'on fait (et il vaut mieux mettre des gros XXX pour expliquer ce qu'il en est).
En fait, meme dans le cas précité strncpy est à bannir, car il produirait un warning avec un compilateur correctement configuré. Je suis partisan d'interdire ce cas pathologique, pour les memes raisons que je refuse les assignations dans expressions de contrôle ( if (n = foo(b)) { ... } ), le traffic des indices de boucles dans le corps des boucles for ou while, les variables globales nommées i, n, ou global, les macros incorrectement parenthésées... pour ne prendre que des exemples évidents. La programmation défensive, c'est toujours une bonne idée.
-- Chqrlie.
"Marc Espie" <espie@lain.home> a écrit dans le message de news:
g7sa00$jdh$2@biggoron.nerim.net...
In article <g7s4bc$c7a$1@registered.motzarella.org>,
Charlie Gordon <news@chqrlie.org> wrote:
Quant à appeler strncpy une fonction qui ne traite *pas* des chaines de
caractères, c'est une erreur de nommage.
Ca, je suis d'accord.
Pour les cas que tu cites, une périphrase avec memset et memcpy est très
simple, lisible et efficace.
Et le code avec strncpy est extremement court, certes un peu bizarre, mais
le format qui va avec l'est aussi (et c'est un peu tard pour le changer).
Le code est court, et les librairies (esp glibc) font des efforts navrants
pour optimiser en ligne, voire en assembleur, les appels à strncpy, au point
d'y introduire des bugs (newlib).
Pour le reste, strncpy n'est pratiquement jamais la bonne solution, et
trop
souvent une source de bugs.
Totalement d'accord.
Mentionner cette fonction dans un tutoriel est une hérésie : le débutant
n'a
aucune chance de comprendre la sémantique tordue de cette saloperie,
surtout
s'il cherche à l'intuiter.
Egalement.
Donc : NE JAMAIS UTILISER LA FONCTION strncpy.
Oui, conseil a la Knuth. A suivre presque toujours, sauf lorsqu'on est
dans le cas de figure pre-cite et qu'on sait exactement ce qu'on fait
(et il vaut mieux mettre des gros XXX pour expliquer ce qu'il en est).
En fait, meme dans le cas précité strncpy est à bannir, car il produirait un
warning avec un compilateur correctement configuré. Je suis partisan
d'interdire ce cas pathologique, pour les memes raisons que je refuse les
assignations dans expressions de contrôle ( if (n = foo(b)) { ... } ), le
traffic des indices de boucles dans le corps des boucles for ou while, les
variables globales nommées i, n, ou global, les macros incorrectement
parenthésées... pour ne prendre que des exemples évidents. La programmation
défensive, c'est toujours une bonne idée.
"Marc Espie" a écrit dans le message de news: g7sa00$jdh$
In article <g7s4bc$c7a$, Charlie Gordon wrote:
Quant à appeler strncpy une fonction qui ne traite *pas* des chaines de caractères, c'est une erreur de nommage.
Ca, je suis d'accord.
Pour les cas que tu cites, une périphrase avec memset et memcpy est très simple, lisible et efficace.
Et le code avec strncpy est extremement court, certes un peu bizarre, mais le format qui va avec l'est aussi (et c'est un peu tard pour le changer).
Le code est court, et les librairies (esp glibc) font des efforts navrants pour optimiser en ligne, voire en assembleur, les appels à strncpy, au point d'y introduire des bugs (newlib).
Pour le reste, strncpy n'est pratiquement jamais la bonne solution, et trop souvent une source de bugs.
Totalement d'accord.
Mentionner cette fonction dans un tutoriel est une hérésie : le débutant n'a aucune chance de comprendre la sémantique tordue de cette saloperie, surtout s'il cherche à l'intuiter.
Egalement.
Donc : NE JAMAIS UTILISER LA FONCTION strncpy.
Oui, conseil a la Knuth. A suivre presque toujours, sauf lorsqu'on est dans le cas de figure pre-cite et qu'on sait exactement ce qu'on fait (et il vaut mieux mettre des gros XXX pour expliquer ce qu'il en est).
En fait, meme dans le cas précité strncpy est à bannir, car il produirait un warning avec un compilateur correctement configuré. Je suis partisan d'interdire ce cas pathologique, pour les memes raisons que je refuse les assignations dans expressions de contrôle ( if (n = foo(b)) { ... } ), le traffic des indices de boucles dans le corps des boucles for ou while, les variables globales nommées i, n, ou global, les macros incorrectement parenthésées... pour ne prendre que des exemples évidents. La programmation défensive, c'est toujours une bonne idée.
-- Chqrlie.
espie
In article <g7vle3$i58$, Charlie Gordon wrote:
"Thierry B." a écrit dans le message de news:
--{ Charlie Gordon a plopé ceci: }--
les fichiers utmp auraient dû être textuels comme tous les fichiers de log.
Sauf que utmp n'est _pas_ un fichier de log. Certains enregistrements sont modifiés 'en place', et donc doivent être d'une taille fixe pour permettre un accès plus ou moins direct. Ce qui explique son aspect un peu étrange et non textuel. Historiquement parlant...
C'est plutot une faiblesse de ce fichier : un bete log des connexions et des deconnexions avec les infos de temps de connexion et autres statistiques au moment de la deconnexion aurait été largement suffisant et bien plus simple à parser par les outils textuels de l'epoque (awk...)
En fait, ca devrait mettre etre organise sous forme d'un repertoire ou chaque terminal depose ses infos dans un fichier separe, ca eviterait la necessite de rajouter un bit s aux xterm et autres (au lieu de faire des aberrations genre le daemon utmper).
mais bon, ca casserait trop de choses cote compatibilite...
In article <g7vle3$i58$1@registered.motzarella.org>,
Charlie Gordon <news@chqrlie.org> wrote:
"Thierry B." <tth@prout.stex.invalid> a écrit dans le message de news:
os49n5-mdg.ln1@prout.stex...
--{ Charlie Gordon a plopé ceci: }--
les fichiers utmp auraient dû être textuels comme tous les fichiers de
log.
Sauf que utmp n'est _pas_ un fichier de log. Certains enregistrements
sont modifiés 'en place', et donc doivent être d'une taille fixe pour
permettre un accès plus ou moins direct. Ce qui explique son aspect
un peu étrange et non textuel. Historiquement parlant...
C'est plutot une faiblesse de ce fichier : un bete log des connexions et des
deconnexions avec les infos de temps de connexion et autres statistiques au
moment de la deconnexion aurait été largement suffisant et bien plus simple
à parser par les outils textuels de l'epoque (awk...)
En fait, ca devrait mettre etre organise sous forme d'un repertoire ou
chaque terminal depose ses infos dans un fichier separe, ca eviterait
la necessite de rajouter un bit s aux xterm et autres (au lieu de faire
des aberrations genre le daemon utmper).
mais bon, ca casserait trop de choses cote compatibilite...
les fichiers utmp auraient dû être textuels comme tous les fichiers de log.
Sauf que utmp n'est _pas_ un fichier de log. Certains enregistrements sont modifiés 'en place', et donc doivent être d'une taille fixe pour permettre un accès plus ou moins direct. Ce qui explique son aspect un peu étrange et non textuel. Historiquement parlant...
C'est plutot une faiblesse de ce fichier : un bete log des connexions et des deconnexions avec les infos de temps de connexion et autres statistiques au moment de la deconnexion aurait été largement suffisant et bien plus simple à parser par les outils textuels de l'epoque (awk...)
En fait, ca devrait mettre etre organise sous forme d'un repertoire ou chaque terminal depose ses infos dans un fichier separe, ca eviterait la necessite de rajouter un bit s aux xterm et autres (au lieu de faire des aberrations genre le daemon utmper).
mais bon, ca casserait trop de choses cote compatibilite...
-ed-
On 14 août, 00:11, "Charlie Gordon" wrote: pour les memes raisons que je refuse les
assignations dans expressions de contrôle ( if (n = foo(b)) { ... } ) , le traffic des indices de boucles dans le corps des boucles for ou while, le s variables globales nommées i, n, ou global, les macros incorrectement parenthésées... pour ne prendre que des exemples évidents. La pr ogrammation défensive, c'est toujours une bonne idée.
+1
On 14 août, 00:11, "Charlie Gordon" <n...@chqrlie.org> wrote:
pour les memes raisons que je refuse les
assignations dans expressions de contrôle ( if (n = foo(b)) { ... } ) , le
traffic des indices de boucles dans le corps des boucles for ou while, le s
variables globales nommées i, n, ou global, les macros incorrectement
parenthésées... pour ne prendre que des exemples évidents. La pr ogrammation
défensive, c'est toujours une bonne idée.
On 14 août, 00:11, "Charlie Gordon" wrote: pour les memes raisons que je refuse les
assignations dans expressions de contrôle ( if (n = foo(b)) { ... } ) , le traffic des indices de boucles dans le corps des boucles for ou while, le s variables globales nommées i, n, ou global, les macros incorrectement parenthésées... pour ne prendre que des exemples évidents. La pr ogrammation défensive, c'est toujours une bonne idée.
