/etc/exports option unsecure

[Marc SCHAEFER]

[ Followup-To: fr.comp.lang.c ]

C'est sans doute pas top, mais au moins c'est différent de la relation
de comparaison, au sens mathématique comme au sens commun.

En fait, le plus grand problème de la notation = (affectation) et ==
(comparaison) apparaît dans les langages très expressifs comme C ou
Perl.

Par exemple en C

if (f = tcp_connect()) {
}

Cela appelle tcp_connect, affecte la valeur à la variable f, puis teste
si c'est différent de zéro. C'est très souvent utilisé et c'est
légitime.

Mais peut-être que le codeur voulait simplement comparer f au résultat
de tcp_connect() sans affecter? Au moins, gcc fait un warning (avec
-Wall), et suggère la forme:

if ((f = tcp_connect())) {
}

pour lui montrer que l'intention était bien d'affecter à f puis de
tester le résultat.

Une bonne pratique si l'on veut éviter une affectation par erreur
(écriture de == remplacée par erreur par =) est la suivante:

# risque si on oublie un =
if (c == 42) {
}

# pas de risque, 42 pas affectable, l'oubli d'un = fera
# une erreur, car la partie gauche n'est pas affectable
if (42 == c) {
}

-- Et pour les afficionados du langage Newton [1]
TAKE PUSH programme;

[1] https://hopl.info/showlanguage.prx?exp=965&language=Newton

[Didier]

Post by Marc SCHAEFER
[ Followup-To: fr.comp.lang.c ]

C'est sans doute pas top, mais au moins c'est différent de la relation
de comparaison, au sens mathématique comme au sens commun.

En fait, le plus grand problème de la notation = (affectation) et ==
(comparaison) apparaît dans les langages très expressifs comme C ou
Perl.
Par exemple en C
if (f = tcp_connect()) {
}
Cela appelle tcp_connect, affecte la valeur à la variable f, puis teste
si c'est différent de zéro. C'est très souvent utilisé et c'est
légitime.
Mais peut-être que le codeur voulait simplement comparer f au résultat
de tcp_connect() sans affecter? Au moins, gcc fait un warning (avec
if ((f = tcp_connect())) {
}
pour lui montrer que l'intention était bien d'affecter à f puis de
tester le résultat.
Une bonne pratique si l'on veut éviter une affectation par erreur
# risque si on oublie un =
if (c == 42) {
}
# pas de risque, 42 pas affectable, l'oubli d'un = fera
# une erreur, car la partie gauche n'est pas affectable
if (42 == c) {
}
-- Et pour les afficionados du langage Newton [1]
TAKE PUSH programme;
[1] https://hopl.info/showlanguage.prx?exp=965&language=Newton

Bonsoir, et merci Marc, c'est très pédagogique, comme toujours de ta part.
Pour un amateur comme moi (autodidacte en plus, la tare quoi !), c'est
toujours bon à prendre. D'autant que j'ai laissé tomber Pascal depuis
pas mal de temps, je ne fais plus que du PHP.
Didier.

[Marc SCHAEFER]

[ Followup-To: fr.comp.lang.php ]

Post by Didier
toujours bon à prendre. D'autant que j'ai laissé tomber Pascal depuis
pas mal de temps, je ne fais plus que du PHP.

En PHP, il y a

= affectation

== comparaison

=== comparaison avec vérification du type

Suivant les versions de PHP, la comparaison suivante donnait un
résultat "vrai":

(42 == "42 toto")

Heureusement, dès 8.x, il semblerait que c'est fini, le nombre étant
plutôt promu en chaîne que le contraire.

Par contre, (42 === "42 toto") a toujours donné un résultat "faux".

Test possible en-ligne ici avec PHP 7 et PHP 8:
https://onlinephp.io/c/8d5e1

En ce qui me concerne, je suis plutôt un développeur
C/bash/Perl/HTML/CSS/SQL, parfois JS.