sorte de self modifying code en C - Page 2

ouais, c'est quand meme un cas particulier, et assez alambiqué, tu admettras.
Maintenant que j'ai le code sous les yeux, je maintiens que ça me parait pas très propre comme bidouille. Surtout que c'est juste pour économiser les 2 octets d'un clr.w
En fait, je sais meme pas si le standard l'autorise. En meme temps, je pense pas qu'ils se soient penché sur des cas aussi tordus ?

int x=x; est une extension GNU.

Ah ok je me disais aussi. Traduit, ça veut dire que ça marche que avec gcc et pas avec autre chose. C'est un choix, mais ça fait une grosse restriction pour deux malheureux octets (un seul sur pc je crois).

Comme par hasard, le seul compilateur valable pour calculatrices TI est TIGCC, donc autant utiliser ses fonctionnalités.

(et paf ds tes dents Pollux )

Peio> Pollux ?
KK> Si tu sais que ton code sera de toutes façons spécifique TI (comme ton code avec Gray3PDBufSetActiveAMSPlane), oui effectivement se restreindre à tigcc n'est pas une restriction très importante .
C'est beaucoup moins vrai si tu développes sur pc par exemple, où il peut etre intéressant de pouvoir utiliser, notamment, le compilateur de microsoft ou de borland pour générer un binaire natif.

Binaire natif? Tu veux dire natif Win32? http://www.mingw.org

spectras :
Peio> Pollux ?

ben oui, le ./34 est clairement une allusion a la "non-existence" de GTC

Kevin Kofler :
int x=x; est une extension GNU.

Supportée aussi par GTC, contrairement à ce que ./34 laisserait sous-entendre

>Je vois pas pkoi ça ne serait pas une correction valable

Parce que si je change le code plus tard, et que x devient rellement non itialise, je ne le verrai plus !
Je prefere laisser le warning, plutot que de faire ce genre de correction.

> for (int i = 0; i < n; ++i)
>alors que n est non signé. L'erreur vient de la déclaration du i, pas du test.

Pas forcement. Tu peux reellement avoir besoin d'avoir i signe (Du genre tu fais des calcules avec i-3).
Et n peut aussi etre parfaitement non-signe (Et logiquement).
La resolution d'un tel cas, est de verifier si n est castable en signed. Sinon soit tu balances une erreur, soit tu fais une deuxieme boucle
imbriquee. Mais meme si ce probleme arrive souvent, la solution complete a celui-ci n'est que tres rarement employee.

> "je sais exactement les implications que ce que je fais va avoir, et je veux que ça se passe comme ça".
Si seulement le programmeur savait ce qu'il faisait, on n'aurait pas invente les warnings.
Ca me rappelle que ce genre de cast est a l'origine d'une vulnerabilite de IE5.5 (Celle qui faisait planter IE avec un BMP).

>1) oui, parce que le compilateur est parfaitement capable d'éliminer les éléments ne servant qu'à la syntaxe et inutile dans la génération du code.
C'est beau l'innocence de la jeunesse

> 2) sans vérifier, je dirais que oui. Mais si tu as un contre-exemple je suis preneur.
Je te previens. Ca utilise des goto / while / for a outrance. Un bel exemple de code incomprehensible.

PS: Je compile avec G++ car il detecte plus de warnings que GCC. Cherchez l'erreur.

./40: >2 >
Mais ca genere un code asm nicquel quel que soit le compilo C utilise

> Maintenant que j'ai le code sous les yeux, je maintiens que ça me parait pas très propre comme bidouille.
Normalement le compilo devrait etre capable de le detecter, non ?

PpHd :
>Je vois pas pkoi ça ne serait pas une correction valable

Parce que si je change le code plus tard, et que x devient rellement non itialise, je ne le verrai plus ! Je prefere laisser le warning, plutot que de faire ce genre de correction.

C'est n'importe quoi, ce prétexte !
Et je dois m'interdire de faire "int x=0;" suivi d'une initialisation conditionnelle de la valeur de x à un truc moins trivial, sous prétexte que si je me loupe dans l'écriture de la condition, alors le compilateur ne pourra pas me sortir un warning comme quoi x n'est pas initialisé ?

(e.g.

int x=-1,y=GetHeight();
if (UserAskWidth()) {
  print("hum...");
  if (CheckIntegerOk()) {
    print("ok");
    x=GetWidth();
  }
  print("!");
}
DrawText(x,y,"bla");

Non, franchement, ce type de warning ne peut de toute façon pas être fiable. Et j'aurais lourdement tendance à penser que le sulfureux "int x=x;" inspire largement plus la méfiance qu'un gentil "int x=-1;"...

Mais meme si ce probleme arrive souvent, la solution complete a celui-ci n'est que tres rarement employee.

J'aurais tendance à penser que ce genre de chose arrive surtout qd le type qui écrit la boucle se dit que de toute façon il n'y aura pas d'overflow Donc la solution peut être tout simplement de passer les "int" en "unsigned int", mais c'est vrai qu'il faut faire gaffe au cas où on utiliserait "i-1" & co...

>1) oui, parce que le compilateur est parfaitement capable d'éliminer les éléments ne servant qu'à la syntaxe et inutile dans la génération du code.

C'est beau l'innocence de la jeunesse

Hum, je dirais plus ça par expérience au contraire. Plus je multiplie les approches, plus je suis impressionné par les capacités d'optimisation de gcc. Notamment, ses techniques d'optimisation sur les architectures risc m'ont impressionné. Moi qui pensais que le c m'enlèverait la possibilité de réordonnancer mes instructions...

Si seulement le programmeur savait ce qu'il faisait, on n'aurait pas invente les warnings.

Ce qui n'empèche pas que au cas par cas, le programmeur peut effectivement savoir qu'il désire obtenir le comportement atypique. Un peu comme je sais plus trop quel programme qui demande de tapper en toutes lettres "Yes, do what I say".

Du genre tu fais des calcules avec i-3

, sauf que si c'est de cet ordre, du peux aussi décaler tes indices, ce qui est quand meme plus simple.

le sulfureux "int x=x;"

On est d'accord que c'est un bricolage douteux, donc.

PS : je compile avec g++ parce que je fais du c++

spectras
:

Si seulement le programmeur savait ce qu'il faisait, on n'aurait pas invente les warnings.

Ce qui n'empèche pas que au cas par cas, le programmeur peut effectivement savoir qu'il désire obtenir le comportement atypique. Un peu comme je sais plus trop quel programme qui demande de tapper en toutes lettres "Yes, do what I say".

Oui.

Du genre tu fais des calcules avec i-3

, sauf que si c'est de cet ordre, du peux aussi décaler tes indices, ce qui est quand meme plus simple.

Si i-3 ne donne pas tjs le résultat voulu, alors c'est que i-3 devient négatif : on ne peut pas changer les indices en restant en "unsigned"...

le sulfureux "int x=x;"

On est d'accord que c'est un bricolage douteux, donc.

Non. Franchement, je préfère écrire ça plutôt que d'initialiser à une valeur bidon (ce qui est encore plus gore) ou ignorer le warning (pareil). Disons que "int x=x;" signifie "Yes, do what I say", je ne vois pas trop le pb Et au contraire, c'est mieux d'avoir un truc qui attire l'attention qu'un truc qui pourrait vouloir dire autre chose ("int x=0;" pourrait vouloir dire n'importe quoi).

Si i-3 ne donne pas tjs le résultat voulu, alors c'est que i-3 devient négatif : on ne peut pas changer les indices en restant en "unsigned"...

Décalage d'indice => plus de i-3. Ca résoud le problème sans avoir besoin de faire plusieurs boucles.

for (i = 0; i < n; ++i)  x[i] = 2*x[i-3] + i;
--------
 x[0] = 2*x[-3] + 0;
 x[1] = 2*x[-2] + 1;
 x[2] = 2*x[-1] + 2;
 for (i = 0; i < n; ++i)  x[i+3] = 2*x[i] + i + 3;

Evidemment, si tu prends un truc un peu plus compliqué t'es obligé de boucler pour faire ton décalage d'indices. Mais c'est pas une boucle imbriquée.

Disons que "int x=x;" signifie "Yes, do what I say"

oui, mais c'est violent. D'autant plus que normalement le x n'est pas censé etre défini avant la fin de l'instruction ? sinon, ça serait pas une extension gcc.
La vraie solution serait de corriger gcc pour qu'il détecte correctement que la variable est initialisée après.

c'est mieux d'avoir un truc qui attire l'attention

Là je suis d'accord. Sur le meme principe que l'utilisation du reinterpret_cast<>() d'ailleurs.

spectras
:

Si i-3 ne donne pas tjs le résultat voulu, alors c'est que i-3 devient négatif : on ne peut pas changer les indices en restant en "unsigned"...

Décalage d'indice => plus de i-3. Ca résoud le problème sans avoir besoin de faire plusieurs boucles.

for (i = 0; i < n; ++i)  x[i] = 2*x[i-3] + i;
--------
 x[0] = 2*x[-3] + 0;
 x[1] = 2*x[-2] + 1;
 x[2] = 2*x[-1] + 2;
 for (i = 0; i < n; ++i)  x[i+3] = 2*x[i] + i + 3;

Evidemment, si tu prends un truc un peu plus compliqué t'es obligé de boucler pour faire ton décalage d'indices. Mais c'est pas une boucle imbriquée.

Ah, mais c'est un cas particulier, les pointeurs. Si j'ai :

void Draw(long xpos);
...
unsigned int n;
for (int i=0;i<n;i++)
  Draw(i-n/2);
...

alors ton truc ne marche pas.

Disons que "int x=x;" signifie "Yes, do what I say"

oui, mais c'est violent. D'autant plus que normalement le x n'est pas censé etre défini avant la fin de l'instruction ? sinon, ça serait pas une extension gcc. La vraie solution serait de corriger gcc pour qu'il détecte correctement que la variable est initialisée après.

PpHd n'a pas tort en disant que c'est beau, l'innocence de la jeunesse Si tu veux résoudre un problème NP-complet en temps polynomial, ben tu es obligé de faire des approximations... Le problème n'est pas une question de fréquence de ces approximations (c'est déjà très rare de devoir utiliser ce genre de choses, dans GTC ça doit apparaître maximum 1 ou 2 fois), mais c'est plutôt de savoir quoi faire si le compilo se plante (il _devra_ se planter à un moment donné, donc on ne peut pas ignorer le pb). On pourrait aussi envisager de faire un

#define undef 123

et faire int x=undef; mais ce serait légèrement moins efficace, et je ne pense pas qu'il y ait des compilos pour qui "int x=x;" soit un problème... (ce n'est pas à proprement parler une violation du standard : x _doit_ être visible au moment de son initialisation, et je ne sais pas s'il y a undefined behaviour dans ce cas... en tout cas n'importe quel compilo vaguement optimisant doit être capable de supprimer l'affectation, donc même sur une architecture tordue où on n'a pas le droit de manipuler des données non initialisées, le pb ne doit pas exister) En revanche il y a des chances que ça ne supprime pas le warning pour tous les compilos.

c'est mieux d'avoir un truc qui attire l'attention

Là je suis d'accord. Sur le meme principe que l'utilisation du reinterpret_cast<>() d'ailleurs.

Vi, donc un truc "voyant" comme "int x=x;" ou "int x=undef;" est préférable...

1) ton exemple est biaisé parce que tu vas avoir un overflow dans ta boucle si n >= 2**31
si le compilo choisit une comparaison signée, tu rentres pas dans la boucle
si le compilo choisit une comparaison non signée, ça fera qqc de louche, mais certainement pas ce à quoi tu t'attendrais, vu que i va passer de +2147483647 à -2147483648 au 2147483648ème tour de boucle
=> c'est effectivement un comportement difficile à émuler avec du code propre .

Et ton exemple est biaisé, parce que tu me demandes d'éliminer le warning dans un cas où il est parfaitement justifié parce qu'il a trouvé un vrai bug dans ton code.

Note : ceci est pour int=32bits. Refaites les calculs sinon

spectras :
1) ton exemple est biaisé parce que tu vas avoir un overflow dans ta boucle si n >= 2**31
si le compilo choisit une comparaison signée, tu rentres pas dans la boucle
si le compilo choisit une comparaison non signée, ça fera qqc de louche, mais certainement pas ce à quoi tu t'attendrais, vu que i va passer de +2147483647 à -2147483648 au 2147483648ème tour de boucle
=> c'est effectivement un comportement difficile à émuler avec du code propre .

Et ton exemple est biaisé, parce que tu me demandes d'éliminer le warning dans un cas où il est parfaitement justifié parce qu'il a trouvé un vrai bug dans ton code.

Note : ceci est pour int=32bits. Refaites les calculs sinon

Euh, j'ai dit où que ça devait être fait automatiquement par le compilo ? PpHd parlait du problème de correction du bug (potentiel) dans "for (signed=0;signed<unsigned;signed++)". Dans l'exemple que j'ai donné, on ne peut pas passer signed en unsigned, même en décalant des indices : on est obligé de faire un cast qq part (dans mon exemple, (long)i-n/2 conviendrait).

(pour mémoire, je répondais à

spectras
:

Du genre tu fais des calcules avec i-3

, sauf que si c'est de cet ordre, du peux aussi décaler tes indices, ce qui est quand meme plus simple.

-> non, on ne peut pas tjs décaler les indices)

Mais tu donnes un exemple qui à la base ne fonctionne pas. (parce que ma démarche sinon aurait été de te présenter le meme sans boucle imbriquée et propre, si c'est possible).

Euh, j'ai dit où que ça devait être fait automatiquement par le compilo ?

J'ai pas dit ça. J'ai dit que le compilo te génère un warning, mais qu'il compile.
Si il compile, il génère donc un test. Et ce test, ce sera soit un test signé, soit un test non signé, y'a pas de test hybride à ma connaissance.

dans mon exemple, (long)i-n/2 conviendrait

Ton exemple ne marche pas, parce qu'il contient un integer overflow. Ton cast est absolument inutile, vu que avant de voir ce qui conviendrait, faudrait commencer par faire marcher le for() lui-meme.

Voilà, avec ces quelques éclairages, je suggère de re-#includer le ./47 ici.

spectras
:Mais tu donnes un exemple qui à la base ne fonctionne pas. <snip ... /> faudrait commencer par faire marcher le for() lui-meme.

Je me suis mal fait comprendre : je n'ai pas donné un exemple qui était censé marcher, j'ai donné un exemple du bug classique décrit dans ./48 (#include ./48 pour plus d'informations ). La correction (que j'ai aussi décrite dans ./48) est la suivante (je vais détailler pour être bien sûr qu'on parle de la même chose) :

void Draw(long xpos); 
 ... 
 unsigned int n; 
 for (unsigned int i=0;i<n;i++) 
   Draw((long)i-n/2); 
 ...

(en supposant que sizeof(int)<sizeof(long))

Elle parfaitement correcte, contrairement à ce que tu dis, et montre bien que

spectras
:

Du genre tu fais des calcules avec i-3

, sauf que si c'est de cet ordre, du peux aussi décaler tes indices, ce qui est quand meme plus simple.

(que je re-cite pour re-mémoire) était inexact.

Voilà, avec ces quelques éclairages, je suggère de re-#includer le ./47 ici.

Ben voyons

Ah, avec un unsigned sur le i dans le for, c'est déjà plus intéressant.
Cela dit, ça donne du code toujours pas terriblement portable, à cause de la supposition sizeof(int) < sizeof(long), alors que en vrai c'est un <=.

Et meme dans ce cas, il ne s'agit plus de sucre syntaxique pour éliminer un warning, comme suggéré au départ, mais de l'ajout d'une réelle opération qui modifie le comportement du programme, l'extension de ta variable.

spectras :
Ah, avec un unsigned sur le i dans le for, c'est déjà plus intéressant.Cela dit, ça donne du code toujours pas terriblement portable, à cause de la supposition sizeof(int) < sizeof(long), alors que en vrai c'est un <=.

Ca redevient portable si on suppose que n est castable en long... (n<=LONG_MAX)
J'avoue que ces histoires de conversions signed/unsigned sont un point assez casse-gueule et platform-dependent... Les langages type Java et C# ont au moins l'avantage de forcer des comportements reproductibles (ils font la supposition très réaliste que le programmeur aura tendance à considérer les comportements sur sa plateforme comme des vérités générales)

Et meme dans ce cas, il ne s'agit plus de sucre syntaxique pour éliminer un warning, comme suggéré au départ, mais de l'ajout d'une réelle opération qui modifie le comportement du programme, l'extension de ta variable.

Mais où ai-je dit qu'il s'agissait de sucre syntaxique ? PpHd parlait des actions à mener en cas d'apparition d'un warning "comparaison signed/unsigned", parlait des problèmes qu'on pouvait rencontrer si on passait l'itérateur en unsigned int (i-3 n'étant plus signé), et toi tu disais que ça pouvait se résoudre avec de simples décalages. En l'occurrence, je te dis que non : ça n'est possible que lorsqu'on manipule des pointeurs, ce qui n'arrive normalement jamais en C++ (#include ./46 pour plus d'infos)

Pollux
:

La vraie solution serait de corriger gcc pour qu'il détecte correctement que la variable est initialisée après.

PpHd n'a pas tort en disant que c'est beau, l'innocence de la jeunesse Si tu veux résoudre un problème NP-complet en temps polynomial, ben tu es obligé de faire des approximations...

Ce problème n'est même pas NP-complet, il est totalement indécidable!

(ce n'est pas à proprement parler une violation du standard : x _doit_ être visible au moment de son initialisation, et je ne sais pas s'il y a undefined behaviour dans ce cas... en tout cas n'importe quel compilo vaguement optimisant doit être capable de supprimer l'affectation, donc même sur une architecture tordue où on n'a pas le droit de manipuler des données non initialisées, le pb ne doit pas exister)

Non, justement, d'après ce que j'ai lu sur la mailing list de GCC, en C ANSI/ISO, la portée de la variable ne commence qu'à la fin de sa déclaration, donc il est interdit d'utiliser x dans la déclaration de x, le compilateur peut parfaitement te balancer une erreur.

PpHd parlait des actions à mener en cas d'apparition d'un warning "comparaison signed/unsigned".

Plus spécifiquement il parlait juste de changer l'interprétation du signe en castant en unsigned ou en signed.
En tous cas, c'est d'après ça que j'ai continué

=> Mais avec unsigned n et unsigned i, on n'a plus la comparaison entre un nombre signé et un non signé. La correction que tu as fait est celle que je mentionnais en ./28, changer en amont le type d'une des variables (ici le i, qui était erroné).

[edit]Ah j'oubliais :

PpHd n'a pas tort en disant que c'est beau, l'innocence de la jeunesse Si tu veux résoudre un problème NP-complet en temps polynomial, ben tu es obligé de faire des approximations...

Je n'ai pas proposé de résoudre le problème. J'ai dit que la vraie solution serait de corriger gcc. Ca n'implique pas que la solution est possible à réaliser.

Kevin Kofler
:

Pollux
:

La vraie solution serait de corriger gcc pour qu'il détecte correctement que la variable est initialisée après.

PpHd n'a pas tort en disant que c'est beau, l'innocence de la jeunesse Si tu veux résoudre un problème NP-complet en temps polynomial, ben tu es obligé de faire des approximations...

Ce problème n'est même pas NP-complet, il est totalement indécidable!

Euh oui Je voulais écrire ça au début, puis j'ai pensé (à tort, évidemment) que ct en fait NP-complet

(ce n'est pas à proprement parler une violation du standard : x _doit_ être visible au moment de son initialisation, et je ne sais pas s'il y a undefined behaviour dans ce cas... en tout cas n'importe quel compilo vaguement optimisant doit être capable de supprimer l'affectation, donc même sur une architecture tordue où on n'a pas le droit de manipuler des données non initialisées, le pb ne doit pas exister)

Non, justement, d'après ce que j'ai lu sur la mailing list de GCC, en C ANSI/ISO, la portée de la variable ne commence qu'à la fin de sa déclaration, donc il est interdit d'utiliser x dans la déclaration de x, le compilateur peut parfaitement te balancer une erreur.

Ah ouais
En tout cas je n'arrive pas à trouver de définition claire de la portée d'une variable dans le standard...

Ah j'oubliais :

PpHd n'a pas tort en disant que c'est beau, l'innocence de la jeunesse Si tu veux résoudre un problème NP-complet en temps polynomial, ben tu es obligé de faire des approximations...

Je n'ai pas proposé de résoudre le problème. J'ai dit que la vraie solution serait de corriger gcc. Ca n'implique pas que la solution est possible à réaliser.

Ben c malin ça... Ta "vraie" solution est *mathématiquement* impossible (même en spectras-logic ), donc je ne vois pas ce que ça t'apporte de critiquer les solutions actuelles alors que c'est le mieux qu'on puisse espérer jamais faire

Mais meme impossible, il n'empèche que c'est comme ça que ce serait propre. La faisabilité de la solution n'entre pas en ligne de compte.
D'ailleurs c'est comme ça qu'ils ont du raisonner les gens chez gnu :
1- la Bonne solution serait que gcc détecte tout bien
2- c'est pas possible
3- donc on fait autrement
=> ça retire rien au fait que la Bonne solution serait que gcc détecte tout bien.

Et la bonne solution serait que les compilateurs n'existent pas parce qu'on aurait le cerveau relié au processeur, donc on n'a pas le droit de parler de compilos et on va passer notre tps à se lamenter sur notre sort ? N'import nawak

"Et la bonne solution serait que les compilateurs n'existent pas parce qu'on aurait le cerveau relié au processeur" => bon, admettons ça comme hypothèse
2) c'est pas possible donc ->
3) on fait avec des compilos, et on a parfaitement le droit d'en parler.
Merci pour ta contribution.

Hum. Je rappelle :

spectras
:

Disons que "int x=x;" signifie "Yes, do what I say"

oui, mais c'est violent. D'autant plus que normalement le x n'est pas censé etre défini avant la fin de l'instruction ? sinon, ça serait pas une extension gcc. La vraie solution serait de corriger gcc pour qu'il détecte correctement que la variable est initialisée après.

Déjà je vois pas où tu aurais pu vouloir en venir, et ensuite le fait de parler de "corriger gcc" sous-entendait que GCC avait un défaut et que l'extension n'était qu'un work-around, et qu'il vaudrait donc mieux le corriger. Et l'aspect conclusif de ta phrase ne laisse pas du tout présager que tu rejettais cette solution...

Enfin bon, c pas grave, on va pas discuter de ça pdt des heures