(je suis débutant en c) je ne vois d'instruction pour boucler

Le 03-12-2009, ? propos de
Re: Norme vs bugs. [etait Re: (je suis débutant en c) je ne vois d'instruction pour boucler],
Marc Boyer ?crivait dans fr.comp.lang.c :

Le 03-12-2009, Antoine Leca <root@localhost.invalid> a écrit :

Normalement si le code marche, personne ne postera ici pour s'en
plaindre.

Pourtant un grnad nombre de fils commencent par « mon code ci-dessous
marche sur XYZ, et bogue quand duchmol essaye sur ABC ». Marchent ou
marchent pas ?

Quand ils n'accusent pas le compilo ABC d'être bugué ;-)
Mes étudiants trouvaient que Sparc était un bien mauvais
processeur, vu qu'il faisait des "bus error" sur des accès
(non alignés) que leur Intel Win/Linux avalait sans broncher.

En fait, même, pour être précis, ils accusaient gcc d'être
bugé, vu que ça marchait sous VC++.

Le problème, c'est que la plupart des développeurs codent sous
i386/amd64. Là, tout de suite, j'essaie de compiler sous sparc64
iFolder, un truc écrit par des pieds en C# qui refuse de compiler sous
en sparcv8+ (pourquoi ? vu qu'il compile en i386...). Résultat des
courses, j'ai dû compiler tous les prérequis (et il y en a) en 64
bits en corrigeant au passage tous les défauts d'alignements mémoire !
Ce n'est pourtant pas dur d'écrire des trucs propres !

Je dis ça parce que je suis fâché et que c'était mon coup de gueule
du soir envers les gdk-pixbuf, les gtk quelque chose et tous les
autres trucs qui ne compilent pas sur des processeurs qui demandent
des alignements mémoire !

JKB

--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.

-ed- écrivit :

On 1 déc, 17:27, candide <cand...@free.invalid> wrote:

Non mais un code qui contient un UB ne peut rien prouver.

OK. Ceci est correct :

int main(void)
{
char i;
printf(" %i n", i ) ;
return 0;
}

Correct en quoi ? Ce n'est pas un bon exemple (au sens de donner
l'exemple), et officiellement c'est un comportement indéterminé
(si char est signé et peut avoir une représentation piège.)

On peut se reporter en particulier à la note 41 (p. 37-38 dans N1256),
2e note du paragraphe 6.2.6.1, dans le 5e alinéa.

41) Thus, an automatic variable can be initialized to a
trap representation without causing undefined
behavior, but the value of the variable cannot be
used until a proper value is stored in it.

Et cela me paraît logique.
(Nonobstant l'idée que semble se faire les programmeurs d'OpenSSL,
cf. CVE 2008 0166 :-) Et hop, je vois déjà Marc sur la moto ! ;-) )


Antoine

Le 03-12-2009, JKB <knatschke@koenigsberg.fr> a écrit :

Le 03-12-2009, ? propos de

En fait, même, pour être précis, ils accusaient gcc d'être
bugé, vu que ça marchait sous VC++.

Le problème, c'est que la plupart des développeurs codent sous
i386/amd64. Là, tout de suite, j'essaie de compiler sous sparc64
iFolder, un truc écrit par des pieds en C# qui refuse de compiler sous
en sparcv8+ (pourquoi ? vu qu'il compile en i386...). Résultat des
courses, j'ai dû compiler tous les prérequis (et il y en a) en 64
bits en corrigeant au passage tous les défauts d'alignements mémoire !
Ce n'est pourtant pas dur d'écrire des trucs propres !

Je dis ça parce que je suis fâché et que c'était mon coup de gueule
du soir envers les gdk-pixbuf, les gtk quelque chose et tous les
autres trucs qui ne compilent pas sur des processeurs qui demandent
des alignements mémoire !

D'autant qu'on peut forcer un x86 à raler en cas d'alignement mémoire
éronné, et qu'un truc qui se prétend portable pourrait ajouter ça
à sa batterie de tests.

Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0

On 3 déc, 16:34, Antoine Leca <r...@localhost.invalid> wrote:

-ed- écrivit :

> On 1 déc, 17:27, candide <cand...@free.invalid> wrote:
>> Non mais un code qui contient un UB ne peut rien prouver.

> OK. Ceci est correct :

> int main(void)
> {
>   char i;
>   printf(" %i n", i ) ;
>   return 0;
> }

Correct en quoi ? Ce n'est pas un bon exemple (au sens de donner
l'exemple), et officiellement c'est un comportement indéterminé
(si char est signé et peut avoir une représentation piège.)

Ah, je croyais qu'il n'y avait pas de trap representation avec les
char...

OK, alors ceci :

#include <stdio.h>

int main (void)
{
unsigned char i;
printf(" %u n", (unsigned) i ) ;
return 0;
}

La valeur de i est indéterminée, mais le comportement est défini.

Marc Boyer wrote:

D'autant qu'on peut forcer un x86 à raler en cas d'alignement mémoire
éronné, et qu'un truc qui se prétend portable pourrait ajouter ça
à sa batterie de tests.

[presque hs] et on fait comment ?

Le 03-12-2009, debug this fifo <debug@fifo.invalid> a écrit :

Marc Boyer wrote:

D'autant qu'on peut forcer un x86 à raler en cas d'alignement mémoire
éronné, et qu'un truc qui se prétend portable pourrait ajouter ça
à sa batterie de tests.

[presque hs] et on fait comment ?

Faut aller positionner des flags CPU à la main.

int main(){
char t[sizeof(double)*2];
double* d= (double*) (t+1);
__asm__("pushfl; popl %eax; orl $0x40000,%eax; pushl %eax; popfl;");
*d= 1.0;
return 0;
}

Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0

Marc Boyer wrote:

D'autant qu'on peut forcer un x86 à raler en cas d'alignement mémoire

int main(){
char t[sizeof(double)*2];
double* d= (double*) (t+1);
__asm__("pushfl; popl %eax; orl $0x40000,%eax; pushl %eax; popfl;");
*d= 1.0;
return 0;
}

grand merci.

Antoine Leca a écrit :

c) ceux qui commentent les réponses, en général parce qu'il ne sont
pas d'accord avec leur contenu ; cela peut dériver ;

Je crois comprendre que tu considères que le groupe c) comme nuisible,

Pas dans l'absolu, mais du point de vue de l'OP d'origine qui ne
comprends plus rien à ce qui dérive de sa question naïve et qui se dit
qu'il est tombé chez les fous d'abstraction bien loin du terrain concret
où lui se situe.

en tous cas à partir d'un certain point de dérive

Et ce point là est tout relatif selon chacun, mais perso je me dit qu'il
vaut mieux mesurer depuis le point de vu de l'OP si on a conservé le
même titre de message. Maintenant si on renomme ou mieux si on crée un
fil séparé sur un sujet qui est devenu manifestement séparé, c'est pas
plus mal pour la relecture plus tard (ou les recherches google).


> <cut> le problème réel est de conserver un bon

rapport signal/bruit.

Tout a fait d'accord.
<cut du reste>

Normalement si le code marche, personne ne postera ici pour s'en
plaindre.

Pourtant un grnad nombre de fils commencent par « mon code ci-dessous
marche sur XYZ, et bogue quand duchmol essaye sur ABC ». Marchent ou
marchent pas ?

Ah ben s'il bogue ca ne colle pas avec le contexte que je décris: "si le
code marche" (sous entendu malgré la faute d'écriture). Perso je n'ai
jamais vu quelqu'un venir se plaindre qu'un prog marche malgré la
présence d'un bug purement théorique qui ne s'est jamais manifesté.

On peut d'ailleurs se poser la question de l'existence d'un tel bug
qu'on a jamais vu. En corrigeant de tels trucs on arrive à vraiment
casser tout le reste. Comme on dit dans la pratique: on ne répare pas un
truc qui marche! (tous ceux qui s'y sont essayés dans la pratique s'en
sont mordus les doigts).

Je ne travaille pas dans une boîte d'informatique, et j'ai donc
évidemment le point de vue opposé. En particulier, je ne suis pas
d'accord sur l'obligation de payer (après la recette) une rente de
situation à mon informaticien pour lui permettre de corriger au fil de
l'eau ses erreurs de programmation, quelles que soient leurs causes,
internes ou externes.

Ca dépend.. il n'y a pas d'obligations. Tu n'es pas obligé d'acheter la
maintenance, mais dans ce cas il ne faut pas venir pleurer que l'outil
ne marche plus avec la dernière version de l'OS, et que du coup tu doive
acheter une nouvelle licence "plein pot" rien que pour ca. Tout change,
même et surtout les OS.

Bien sûr, il est des cas où c'est économiquement plus intéressant de
faire comme cela : ainsi une équipe qui dispose de compétences stables
dans le temps peut montrer qu'il est plus rentable de mettre en place le
programme dès qu'il remplit à peu près les objectifs, et qu'ensuite on
corrige les erreurs au fur et à mesure de leurs diagnostics ;

Le problème est qu'aucun programme n'existe "sans bugs". C'est comme les
documents sans fautes: on a beau faire lire et relire un texte, à la
10eme lecture on trouve encore des fautes et c'est pareil avec les
progs: il y a toujours un bug qui se cache quelque part. Typiquement les
bugs apparaissent parce qu'on a changé le cas d'utilisation, ou le
contexte d'utilisation. Tant que le bug ne s'est pas manifesté on croit
que le prog est fiable, mais c'est rarement le cas. Comme disait
Molière: toute personne en bonne santé est un malade qui s'ignore.

Tout ce qu'il faut faire c'est coder proprement pour limiter
l'importance des bugs (en nombre et en conséquences).

<cut>

Il est aussi des cas où ce n'est pas une bonne idée. Quand tu envoies
une fusée dans l'espace, ou même si tu diffuses un produit grand public
à des millions d'exemplaires, il n'est pas encore admis par tout le
monde que le code devra peut-être évoluer dans le futur...

Détrompe toi: tout est conçu pour évoluer de nos jours. Deux exemples:

1. L'espace: tous les trucs envoyés sont prévus pour être reprogrammés.
Il arrive en effet souvent qu'on trouve sur le terrain un bug qui ne
s'était manifesté dans aucune des campagnes de tests. Parfois même on a
reprogrammé en cours de route une sonde à quelques heures-lumières de la
terre (je crois qu'elle était en direction d'un satellite de saturne)
parce qu'on venait de découvrir un soucis dans le logiciel embarqué.

2. Le grand public. Si tu as un décodeur TNT tu trouveras une chaîne
curieuse appelée ATH (Association du téléchargement hertzien). Et bien
ce sont les fabriquants de TV qui utilisent ce canal pour transmettre
les "patchs" (appelées mise-à-jour pour ne pas faire peur au grand
public) aux TV.

Tu me dira que oui mais bon la TV c'est pas grave d'avoir une mise à
jour, c'est accessoire et pas sécuritaire. Soit. et bien si tu as une
voiture plus ou moins moderne, demande à ton concessionnaire qu'il
branche son lexia à l'ordinateur de bord et te liste les mises à jour
suite à des OTS (opérations technique spéciale) qu'ils ont réalisés lors
des visites d'entretien du véhicule. C'est affolant de voir comment les
voitures sont patchées de nos jours. Si le grand public savait, il
éviteraient certains modèles avec plein d'ECU dedans ;-)

Et oui les bugs existent, c'est la vie. Et tant qu'un logiciel tourne
dans la nature, il faut prévoir de la maintenance autour pour corriger
les bugs qui auraient échappés à la détection jusque là.

sam.

Samuel Devulder a écrit :

Et oui les bugs existent, c'est la vie...

Vous disiez que globalement un logiciel non bogué, c'était
un logiciel mort également plus haut dans le fil. Vous avez
sûrement raison d'une manière générale. Et Knuth avec TeX
alors ? :-)
J'avais entendu dire que très peu de bugs ont été détectés
et que les quelques rares bugs ont été détectés par
ordinateur uniquement, est-ce vrai ?




--
François Lafont

Francois, le 03/12/2009 a écrit :

Samuel Devulder a écrit :

Et oui les bugs existent, c'est la vie...

Vous disiez que globalement un logiciel non bogué, c'était un logiciel mort
également plus haut dans le fil. Vous avez sûrement raison d'une manière
générale. Et Knuth avec TeX alors ? :-)
J'avais entendu dire que très peu de bugs ont été détectés et que les
quelques rares bugs ont été détectés par ordinateur uniquement, est-ce vrai ?

non

--
Pierre Maurette