Comparaison entre pointeurs

[Taurre]

Bonjour à tous,

En lisant la norme C au sujet du comportement des opérateurs de
comparaisons (<, <=, > et =>), j'ai vu que dans le cas où deux
pointeurs référencent des objets n'appartenant pas au même agrégat, le
comportement est indéterminé (C11 [n1570] § 6.5.8 Relational operators
al 5 pp 95-96).

Comparer l'adresse de deux objets ne faisant pas partie du même
agrégat ne me paraît pas avoir beaucoup de sens, mais j'aurais voulu
savoir pourquoi il s'agit d'un comportement indéterminé ? Je veux
dire, techniquement, les pointeurs ne sont généralement rien de plus
que des entiers, aussi, en quoi leur comparaison serait-elle
problématique hormis les cas cités par la norme ? Existe-t-il des
architectures recourant à des représentations pouvant être
problématique en cas de comparaison ? Si oui, auriez-vous des
exemples ?

Merci d'avance pour vos réponses :)

[Erwan David]

Taurre <jerome....@yahoo.fr> �crivait�:

>
> En lisant la norme C au sujet du comportement des op�rateurs de
> comparaisons (<, <=, > et =>), j'ai vu que dans le cas o� deux
> pointeurs r�f�rencent des objets n'appartenant pas au m�me agr�gat, le
> comportement est ind�termin� (C11 [n1570] � 6.5.8 Relational operators
> al 5 pp 95-96).
>
> Comparer l'adresse de deux objets ne faisant pas partie du m�me
> agr�gat ne me para�t pas avoir beaucoup de sens, mais j'aurais voulu
> savoir pourquoi il s'agit d'un comportement ind�termin� ? Je veux
> dire, techniquement, les pointeurs ne sont g�n�ralement rien de plus

> que des entiers, aussi, en quoi leur comparaison serait-elle

> probl�matique hormis les cas cit�s par la norme ? Existe-t-il des
> architectures recourant � des repr�sentations pouvant �tre
> probl�matique en cas de comparaison ? Si oui, auriez-vous des
> exemples ?
>
> Merci d'avance pour vos r�ponses :)

Prends la m�moire segment�e des 8086, avec les overlapping tu pouvais
avoir des pointeurs diff�rents pointant sur la m�me adresse ou des
pointeurs avec un poids fort plus �lev� mais qui se trouvaient avant
dans la m�moire.

--
Le travail n'est pas une bonne chose. Si �a l'�tait,
les riches l'auraient accapar�

[Jean-Marc Bourguet]

On pouvait aussi d�cider de ne comparer que l'offset dans les mod�les
m�moires ne permettant pas des objets de plus de 64K (quasiment tous). Donc
avoir p1 <= p2 && p1 >= p2 && p1 != p2 (offsets �gaux, segments diff�rents,
<= et >= comparent que les offsets, != compare offsets et segments).

A+
--
Jean-Marc
FAQ de fclc: http://www.levenez.com/lang/c/faq
Site de usenet-fr: http://www.usenet-fr.news.eu.org

[Erwan David]

Jean-Marc Bourguet <j...@bourguet.org> �crivait�:

On pouvaiut, mais ce n'�tait pas obligatoire. Donc comportement ind�fini
(par la norme). Une impl�mentation est alors cens�e indiquer ce qu'elle fait.

[Marc Espie]

In article <m2a9y9v...@rail.eu.org>,
Erwan David <er...@rail.eu.org> wrote:
>Jean-Marc Bourguet <j...@bourguet.org> �crivait�:

>> On pouvait aussi d�cider de ne comparer que l'offset dans les mod�les
>> m�moires ne permettant pas des objets de plus de 64K (quasiment tous). Donc
>> avoir p1 <= p2 && p1 >= p2 && p1 != p2 (offsets �gaux, segments diff�rents,
>> <= et >= comparent que les offsets, != compare offsets et segments).
>>
>
>On pouvaiut, mais ce n'�tait pas obligatoire. Donc comportement ind�fini
>(par la norme). Une impl�mentation est alors cens�e indiquer ce qu'elle fait.

Attention, de la maniere dont tu formules les choses, tu melanges
"undefined behavior" et "implementation defined defined", ce qui n'est
pas gentil pour les debutants qui nous lisent.

Une implementation "n'est PAS censee indiquer ce qu'elle fait" ! J'ai
reverifie ma norme, la comparaison entre pointeurs non correles est bien
une "undefined behavior"

Il peut donc se passer relativement n'importe quoi dans le cadre du C
standard.

[Erwan David]

es...@lain.home (Marc Espie) écrivait :

> In article <m2a9y9v...@rail.eu.org>,
> Erwan David <er...@rail.eu.org> wrote:

>>Jean-Marc Bourguet <j...@bourguet.org> écrivait :
>>> On pouvait aussi décider de ne comparer que l'offset dans les modèles
>>> mémoires ne permettant pas des objets de plus de 64K (quasiment tous). Donc
>>> avoir p1 <= p2 && p1 >= p2 && p1 != p2 (offsets égaux, segments différents,

>>> <= et >= comparent que les offsets, != compare offsets et segments).
>>>
>>

>>On pouvaiut, mais ce n'était pas obligatoire. Donc comportement indéfini
>>(par la norme). Une implémentation est alors censée indiquer ce qu'elle fait.

>
> Attention, de la maniere dont tu formules les choses, tu melanges
> "undefined behavior" et "implementation defined defined", ce qui n'est
> pas gentil pour les debutants qui nous lisent.
>
> Une implementation "n'est PAS censee indiquer ce qu'elle fait" ! J'ai
> reverifie ma norme, la comparaison entre pointeurs non correles est bien
> une "undefined behavior"
>
> Il peut donc se passer relativement n'importe quoi dans le cadre du C
> standard.

Oui, mea culpa, j'ai effectivement mélangé les 2 notions. undefined
c'est undefined et ça peut faire n'importe quoi.

--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé

[Taurre]

Merci pour vos réponses, j'y vois désormais plus clair à ce sujet :)
Il me reste cependant une petite question :

> J'ai reverifie ma norme, la comparaison entre pointeurs non correles est bien

> une "undefined behavior".

> Il peut donc se passer relativement n'importe quoi dans le cadre du C standard.

C'est en effet ce qui me perturbe. Que la mémoire soit ou non
segmentée, les pointeurs restent des entiers, les comparer ne doit
donc pas poser de problème. Existe-t-il des architectures où une telle
comparaison provoquerait une erreur (comme par exemple l'émission d'un
signal) ?

[Marc]

Taurre wrote:

> Bonjour � tous,

>
> En lisant la norme C au sujet du comportement des op�rateurs de
> comparaisons (<, <=, > et =>), j'ai vu que dans le cas o� deux
> pointeurs r�f�rencent des objets n'appartenant pas au m�me agr�gat, le

> comportement est ind�termin� (C11 [n1570] � 6.5.8 Relational operators
> al 5 pp 95-96).

Une note pour meubler�: C++, qui a le m�me op�rateur < que le C, fournit
� c�t� std::less qui d�finit un ordre total sur les pointeurs (de m�me
type).

[Erwan David]

Taurre <jerome....@yahoo.fr> écrivait :

On peut imaginer des archis où la comparaison fasse intervenir une
différence et qu'une différence de pointeurs dans des aggrégats
différents provoque un plantage (il n'y a pas que les OC, si tu vas du
côté de l'embarqué ou d'archis un peu anciennes tu as des modèles de
mémoire très différents. Un avantage de C est que les définitions
s'appliquent aussi sur ces archis, permettant d'avoir une très grosse
majorité de code portable (en C strict) et quelques pourcents du code
spécifiques à l'archi.

[Jean-Marc Bourguet]

Taurre <jerome....@yahoo.fr> writes:

> Merci pour vos r�ponses, j'y vois d�sormais plus clair � ce sujet :)

> Il me reste cependant une petite question :
>
>> J'ai reverifie ma norme, la comparaison entre pointeurs non correles est bien
>> une "undefined behavior".
>> Il peut donc se passer relativement n'importe quoi dans le cadre du C standard.
>

> C'est en effet ce qui me perturbe. Que la m�moire soit ou non
> segment�e, les pointeurs restent des entiers, les comparer ne doit
> donc pas poser de probl�me. Existe-t-il des architectures o� une telle
> comparaison provoquerait une erreur (comme par exemple l'�mission d'un
> signal) ?

Pour commencer, dans une architecture segment�e, les pointeurs sont des
paires dont les premiers �l�ments ne sont pas n�cessairement logiquement
ordonn�s et qui peuvent avoir des �quivalences non triviales.

D'une part, si on quelque chose unspecified behavior, il faut donner la
liste des comportements possibles, ce qu'on n'a pas n�cessairement envie de
faire.

De plus reprends l'exemple que j'ai donn� (p1 <= p2 && p1 >= p2 && p1 !=
p2, on peut avoir aussi p1 < p2, p2 < p3 et p4 == p3, p4 < p1) et imagine
ce que �a peut donner si tu as un optimiseur qui suppose raisonnablement
que �a ne peut pas �tre le cas (et on n'a peut-�tre pas envie de compliquer
l'optimiseur pour lui apprendre quand il ne faut pas supposer �a).


La comparaison entre pointeurs arbitraires est parfois utile. C++ fournit
std::less pour comparer les pointeurs et de m�moire POSIX impose un ordre
total dans tous les cas (j'ai pas le temps de v�rifier, si quelqu'un l'a,
j'appr�cierais la confirmation). On aurait aussi pu d�sirer que le cas de
void* soit d�finit de la m�me mani�re, ce qui aurait fournit la possibilit�
de l'avoir en C sans trop g�ner les impl�mentations, mais ce n'est pas le
cas.

[Marc Espie]

In article <c292b9d8-46ce-4020...@c11g2000yqb.googlegroups.com>,
Taurre <jerome....@yahoo.fr> wrote:
>Merci pour vos r�ponses, j'y vois d�sormais plus clair � ce sujet :)

>Il me reste cependant une petite question :
>
>> J'ai reverifie ma norme, la comparaison entre pointeurs non correles est bien
>> une "undefined behavior".
>> Il peut donc se passer relativement n'importe quoi dans le cadre du C
>standard.
>

>C'est en effet ce qui me perturbe. Que la m�moire soit ou non
>segment�e, les pointeurs restent des entiers, les comparer ne doit
>donc pas poser de probl�me. Existe-t-il des architectures o� une telle
>comparaison provoquerait une erreur (comme par exemple l'�mission d'un
>signal) ?

Il faut *vraiment* que tu changes de mode de fonctionnement vis-a-vis du
langage, ca t'evitera des problemes.

Les questions du genre "je ne comprend pas, sur toutes les archis que je
connais, ca marche comme ca, comment peut-on faire autrement", c'est la
meilleure facon de chercher les emmerdes.

Il y *a* des archis exotiques. Tous les "undefined behavior" de la norme
en proviennent. Dans certains cas, tu vas avoir du mal a avoir une "preuve
d'existence", sous forme d'une archi sur laquelle ca chie (deja, tu auras
parfois du mal a trouver des gens qui ont ces archis sous la main ou qui en
ont eu l'experience).

Si tu pars dans l'idee de "oh ben, ca doit etre implemente comme ca, parce
que je n'arrive pas a imaginer que ca puisse etre autrement", tu auras tot
ou tard des problemes. Plutot tot, en fait, Murphy aidant. Suffit que tu
depende d'un comportement mal defini pour que quelqu'un essaie de faire
tourner ton code sur une archi ou ca chie (ca ne rate presque jamais).

Et meme: c'est un mauvais etat d'esprit pour faire du code robuste, donc
de qualite, et encore plus si tu veux faire de la securite informatique.

Il faut beaucoup, beaucoup d'imagination pour trouver toutes les facons dont
un code peut merder. Mais en fait, ca n'est pas important, parce qu'il y a
une seule facon dont ce code peut marcher... c'est beaucoup plus simple,
et infiniment moins generateur d'emmerdes, de decider qu'on va se placer
dans LE cas ou les choses marchent, LE cas du comportement defini.

A force de vouloir avoir des contre-exemples... on en oublierait presque
qu'au final, le but, c'est de faire des choses qui fonctionnent.

[Jean-Marc Bourguet]

es...@lain.home (Marc Espie) writes:

> Il y *a* des archis exotiques. Tous les "undefined behavior" de la norme
> en proviennent.

Je ne suis pas sur que ce soit le cas de tous (modifier deux fois un
objet sans point de sequencement entre les modif p.e.), mais une partie.
Et surtout, le plus gros consommateur de ces latitudes, c'est
l'optimiseur. Meme si la raison, c'est une archi exotique, ce qui
risque le plus de poser probleme, c'est l'optimiseur.


Les optimiseurs fonctionnent sur le mode "c'est de l'UB, ca ne peut pas
arriver, j'en deduis tout ce que je peux et je propage l'info le plus
loin possible -- apres et *avant* le moment ou l'UB a lieu -- pour en
profiter". Avec

if (p == NULL) {
// on peut prouver que p n'est pas modifie
}
p->x = 42;

J'ai deja vu une version de gcc virer le if. Qui etait de
l'instrumentation venant d'etre ajoutee pour voir pourquoi le programme
plantait, ce qui etait particulierement perturbant. (Dans ce cas,
l'optimisation a ete viree avant la release de gcc parce que trop
surprenante, mais pas sans debats; gcc continue a faire des choses
analogues pour l'overflow -- au moins il y a -fwrapv pour les supprimer,
mais il n'y a pas de flag, "ne fait que des optimisations raisonnables"
et pour cause, personne n'est d'accord sur la definition d'optimisation
raisonnable).

[Antoine Leca]

Taurre �crivit :

>> J'ai reverifie ma norme, la comparaison entre pointeurs non correles est bien
>> une "undefined behavior".
>> Il peut donc se passer relativement n'importe quoi dans le cadre du C standard.
>

> C'est en effet ce qui me perturbe. Que la m�moire soit ou non

> segment�e, les pointeurs restent des entiers,

... mais il n'est pas garanti par la norme que les entiers (math) en
question soient manipulables en tant qu'entiers C. Exemple le plus
�vident : un compilateur C90 pour l'architecture 64 bits de Microsoft:
long est un type 32 bits, et les pointeurs sont sur 64 bits...

Autre exemple : le langage d�finit le type ptrdiff_t pour traiter les
diff�rence entre pointeurs (sous-entendu � corr�l�s �). Sur les
architectures mixtes 32/64 (genre x86-64), il est parfaitement l�gitime
d'utiliser un type sur 32 bits pour ce faire, si le compilateur suppose
par ailleurs que le programme ne va consid�rer qu'un espace m�moire
limit� � 31 ou 32 bits (cas par exemple du mod�le "x32") ; et
�videmment, une comparaison entre deux pointeurs � non corr�l�s � peut
faire exploser les compteurs.

Par ailleurs, l'affirmation � les pointeurs sont des entiers � me g�ne
aux entournures. M�me si je sais bien que ces temps-ci, �tout le monde�
travaille avec des architectures lin�aires. En effet, ce genre
d'affirmation suppose (indument) que les repr�sentations des pointeurs
partagent *toutes* les propri�t�s des entiers (des ordinateurs,
c'est-�-dire un intervalle en terme math�matique). Et ce n'est en
pratique pas le cas : certaines valeurs ne repr�sentent pas des
pointeurs valables, d'autres valeurs sont magiques, parfois des
diff�rences entre deux valeurs peuvent avoir un sens (comme entre deux
pointeurs vers le m�me objet), parfois pas (comme par exemple entre deux
d�clarations adjacentes de deux pointeurs, qui sont al�atoires, au sens
d'une variable al�atoire), etc.


> les comparer ne doit donc pas poser de probl�me.

Cf. supra pour d'�ventuels probl�mes.
Par ailleurs, quel est l'int�r�t de faire une op�ration n'ayant pas de
signification ? Juste pour pousser la norme dans ses retranchements ?


Antoine

[Marc Espie]

In article <jvomhq$q78$1...@shakotay.alphanet.ch>,

Antoine Leca <ro...@localhost.invalid> wrote:
>Par ailleurs, l'affirmation � les pointeurs sont des entiers � me g�ne
>aux entournures. M�me si je sais bien que ces temps-ci, �tout le monde�
>travaille avec des architectures lin�aires. En effet, ce genre
>d'affirmation suppose (indument) que les repr�sentations des pointeurs
>partagent *toutes* les propri�t�s des entiers (des ordinateurs,
>c'est-�-dire un intervalle en terme math�matique). Et ce n'est en
>pratique pas le cas : certaines valeurs ne repr�sentent pas des
>pointeurs valables, d'autres valeurs sont magiques, parfois des
>diff�rences entre deux valeurs peuvent avoir un sens (comme entre deux
>pointeurs vers le m�me objet), parfois pas (comme par exemple entre deux
>d�clarations adjacentes de deux pointeurs, qui sont al�atoires, au sens
>d'une variable al�atoire), etc.

Petite parenthese, j'avais note dans mes commentaires initiaux (qui vont
dans ton sens "en C standard").

Il est *evident* que, dans certains domaines d'application, on fait des
hypotheses supplementaires concernant l'acces a la memoire. Par exemple,
le code noyau d'un Unix-like moderne ecrit en C sur une architecture mainstream
*va* manipuler des pointeurs comme des entiers. Il y a parfois des soucis
concernant le caractere signe ou non de ces pointeurs. Et il y a parfois
quelques soucis concernant certains compilos mainstream qui sont souvent
utilises pour compiler les dits-noyaux (pas tres dur de retrouver des
grosses engueulades entre Linus et l'equipe de dev de gcc), qui mettent
surtout en evidence la necessite pour un compilo *generaliste* d'etre
equipe d'options *permettant de desactiver tout une batterie d'optimisations
user-land* qui vont poser probleme lors de la compilation noyau.

Mais on peut facilement etre d'accord que tout ceci est de l'application
de niche... sauf si on veut bosser sur ce genre de choses, supposer des
choses sur les pointeurs est une connerie.

Suffit d'etre assez vieux pour avoir vu passer quelques generations
d'architecture et voir des hypotheses plus ou moins raisonnables a l'instant
t s'averer completement debiles a l'instant T+1.

Experience perso: le basic amiga, pondu par microsoft, deja mauvais a
l'epoque, qui avait cru intelligent de stocker ses info de gc sur les 8 bits de
poids fort des pointeurs, vu que, sur les premiers amiga, a base de 68000,
le bus d'adresse etait limite a 24 bits...

[Jean-Marc Bourguet]

es...@lain.home (Marc Espie) writes:

> Experience perso: le basic amiga, pondu par microsoft, deja mauvais a
> l'epoque, qui avait cru intelligent de stocker ses info de gc sur les
> 8 bits de poids fort des pointeurs, vu que, sur les premiers amiga, a
> base de 68000, le bus d'adresse etait limite a 24 bits...

Erreur (utiliser les 8 bits de poids forts de pointeur parce que
l'espace memoire est limite a 24 bits) qui a ete faite au moins deux
autres fois. Sur les premier Mac et les IBM 360 (la, c'etait grave au
point que quand ils ont fait l'extension sur 32 bits -- prevue depuis le
debut -- ils n'ont pu utiliser que 31 bits).

L'autre cote de la piece, c'est la reponse "si on n'avait pas fait ca,
on aurait ete moins bon et perdu tant de part de marche qu'on aurait pas
survecu pour en profiter". Difficile pour moi de savoir a quel point
c'est vrai.

Mais c'est fou ce qu'on se traine longtemps les consequences des choix.

[Marc Espie]

In article <pxbr4rk...@bourguet.org>,

Jean-Marc Bourguet <j...@bourguet.org> wrote:
>L'autre cote de la piece, c'est la reponse "si on n'avait pas fait ca,
>on aurait ete moins bon et perdu tant de part de marche qu'on aurait pas
>survecu pour en profiter". Difficile pour moi de savoir a quel point
>c'est vrai.

bullshit.

[Taurre]

On 6 août, 00:27, es...@lain.home (Marc Espie) écrivit:

> Il faut *vraiment* que tu changes de mode de fonctionnement vis-a-vis du
> langage, ca t'evitera des problemes.
>
> Les questions du genre "je ne comprend pas, sur toutes les archis que je
> connais, ca marche comme ca, comment peut-on faire autrement", c'est la
> meilleure facon de chercher les emmerdes.
>
> Il y *a* des archis exotiques. Tous les "undefined behavior" de la norme
> en proviennent. Dans certains cas, tu vas avoir du mal a avoir une "preuve
> d'existence", sous forme d'une archi sur laquelle ca chie (deja, tu auras
> parfois du mal a trouver des gens qui ont ces archis sous la main ou qui en
> ont eu l'experience).
>
> Si tu pars dans l'idee de "oh ben, ca doit etre implemente comme ca, parce
> que je n'arrive pas a imaginer que ca puisse etre autrement", tu auras tot
> ou tard des problemes. Plutot tot, en fait, Murphy aidant. Suffit que tu
> depende d'un comportement mal defini pour que quelqu'un essaie de faire
> tourner ton code sur une archi ou ca chie (ca ne rate presque jamais).
>
> Et meme: c'est un mauvais etat d'esprit pour faire du code robuste, donc
> de qualite, et encore plus si tu veux faire de la securite informatique.
>
> Il faut beaucoup, beaucoup d'imagination pour trouver toutes les facons dont
> un code peut merder. Mais en fait, ca n'est pas important, parce qu'il y a
> une seule facon dont ce code peut marcher... c'est beaucoup plus simple,
> et infiniment moins generateur d'emmerdes, de decider qu'on va se placer
> dans LE cas ou les choses marchent, LE cas du comportement defini.
>
> A force de vouloir avoir des contre-exemples... on en oublierait presque
> qu'au final, le but, c'est de faire des choses qui fonctionnent.

En fait, ma question tient purement de la curiosité (peut-être
malsaine, j'avoue). Lorsque je programme, j'essaye de me tenir à la
norme afin de maximiser la portabilité de mon code. Cependant, j'aime
toujours de savoir d'où provient telle ou telle restriction et
d'apprendre comment certaines architectures implémentent les concepts
du C. C'est entre autre pour cela que j'aime poser mes questions au
sujet de la norme ici, car je sais qu'il y a des gens d'expérience qui
pourront le plus souvent m'éclairer avec du concret.

Sinon, merci à tous pour vos réponses, je pense désormais mieux voir
dans quels cas de tels comparaisons pourraient être problématique.

[Tonton Th]

On 08/06/2012 09:46 AM, Jean-Marc Bourguet a dit:

> surprenante, mais pas sans debats; gcc continue a faire des choses
> analogues pour l'overflow -- au moins il y a -fwrapv pour les supprimer,
> mais il n'y a pas de flag, "ne fait que des optimisations raisonnables"

Même -O0 ?


--

Nous vivons dans un monde étrange/
http://foo.bar.quux.over-blog.com/

[Jean-Marc Bourguet]

Tonton Th <t...@la.bas.invalid> writes:

> On 08/06/2012 09:46 AM, Jean-Marc Bourguet a dit:
>
>> surprenante, mais pas sans debats; gcc continue a faire des choses
>> analogues pour l'overflow -- au moins il y a -fwrapv pour les supprimer,
>> mais il n'y a pas de flag, "ne fait que des optimisations raisonnables"
>

> M�me -O0 ?

�a c'est "ne faut aucune optimisation, m�me pas les raisonnables et
tellement �vidente que les autres compilateurs ne permettent pas de les
supprimer."

[Tonton Th]

On 08/06/2012 06:05 PM, Jean-Marc Bourguet a dit:

> Erreur (utiliser les 8 bits de poids forts de pointeur parce que
> l'espace memoire est limite a 24 bits) qui a ete faite au moins deux
> autres fois. Sur les premier Mac et les IBM 360 (la, c'etait grave au
> point que quand ils ont fait l'extension sur 32 bits -- prevue depuis le
> debut -- ils n'ont pu utiliser que 31 bits).

Tu as oubli� les premi�res s�rie des Atari ST (ceux � 68000) o�
les acc�s aux p�riph�riques (68901 et ay3-8910) pouvaient se faire
bien plus rapidement en n�gligeant les 8 bits de poids fort du
bus d'adresse. Bien pratique en asm/superviser, mais diabolique
� g�rer en C ;)

--

Nous vivons dans un monde �trange/
http://foo.bar.quux.over-blog.com/

[Marc Espie]

In article <50bb907e$0$1952$426a...@news.free.fr>,

Tonton Th <t...@la.bas.invalid> wrote:
>On 08/06/2012 09:46 AM, Jean-Marc Bourguet a dit:
>
>> surprenante, mais pas sans debats; gcc continue a faire des choses
>> analogues pour l'overflow -- au moins il y a -fwrapv pour les supprimer,
>> mais il n'y a pas de flag, "ne fait que des optimisations raisonnables"
>

> M�me -O0 ?

-O0 fait parfois des non-optimisations pas raisonnables du tout, comme
de deposer des zeros dans les variables non initialisees.

(je crois que ca a finalement ete corrige en 4.x)

[Marc Espie]

In article <50bbaf1c$0$16500$426a...@news.free.fr>,

Tonton Th <t...@la.bas.invalid> wrote:
>On 08/06/2012 06:05 PM, Jean-Marc Bourguet a dit:
>
>> Erreur (utiliser les 8 bits de poids forts de pointeur parce que
>> l'espace memoire est limite a 24 bits) qui a ete faite au moins deux
>> autres fois. Sur les premier Mac et les IBM 360 (la, c'etait grave au
>> point que quand ils ont fait l'extension sur 32 bits -- prevue depuis le
>> debut -- ils n'ont pu utiliser que 31 bits).
>

> Tu as oublié les premières série des Atari ST (ceux à 68000) où
> les accès aux périphériques (68901 et ay3-8910) pouvaient se faire
> bien plus rapidement en négligeant les 8 bits de poids fort du

> bus d'adresse. Bien pratique en asm/superviser, mais diabolique

> à gérer en C ;)

Et le Basic Microsoft sur amiga... qui ne marche que sur les modeles
a base de 68000, parce que lui aussi utilise les 8 bits de poids fort
pour autre chose...

[Alexandre Bacquart]

On 12/02/2012 08:42 PM, Tonton Th wrote:
> On 08/06/2012 06:05 PM, Jean-Marc Bourguet a dit:
>
>> Erreur (utiliser les 8 bits de poids forts de pointeur parce que
>> l'espace memoire est limite a 24 bits) qui a ete faite au moins deux
>> autres fois. Sur les premier Mac et les IBM 360 (la, c'etait grave au
>> point que quand ils ont fait l'extension sur 32 bits -- prevue depuis le
>> debut -- ils n'ont pu utiliser que 31 bits).
>

> Tu as oublié les premières série des Atari ST (ceux à 68000)

?? Tous les Atari ST ont toujours eu un 68000 (pédalant à 8Mhz, puis
16Mhz pour les Mega STe). L'Atari TT fut le premier modèle à évoluer
avec le 68030.

Haaa mon Atari STe ! J'ai commencé C avec ça (avec le compilo "Pure C"
il me semble). Avant, je faisais quasiment que de l'assembleur ;)


--
Alexandre

[Alexandre Bacquart]

On 12/03/2012 12:43 AM, Marc Espie wrote:
> In article<50bb907e$0$1952$426a...@news.free.fr>,
> Tonton Th<t...@la.bas.invalid> wrote:
>> On 08/06/2012 09:46 AM, Jean-Marc Bourguet a dit:
>>
>>> surprenante, mais pas sans debats; gcc continue a faire des choses
>>> analogues pour l'overflow -- au moins il y a -fwrapv pour les supprimer,
>>> mais il n'y a pas de flag, "ne fait que des optimisations raisonnables"
>>

>> Même -O0 ?

>
> -O0 fait parfois des non-optimisations pas raisonnables du tout, comme
> de deposer des zeros dans les variables non initialisees.
>
> (je crois que ca a finalement ete corrige en 4.x)

Ouf ! Il faudrait même une option pour y fiche des valeurs aléatoires
(autre que 0). Ca existe ?


--
Alexandre

[Jean-Marc Bourguet]

Tonton Th <t...@la.bas.invalid> writes:

> On 08/06/2012 06:05 PM, Jean-Marc Bourguet a dit:
>
>> Erreur (utiliser les 8 bits de poids forts de pointeur parce que
>> l'espace memoire est limite a 24 bits) qui a ete faite au moins deux

^^^^^^^^

>> autres fois. Sur les premier Mac et les IBM 360 (la, c'etait grave au
>> point que quand ils ont fait l'extension sur 32 bits -- prevue depuis le
>> debut -- ils n'ont pu utiliser que 31 bits).
>

> Tu as oublié les premières série des Atari ST (ceux à 68000) où

> les accès aux périphériques (68901 et ay3-8910) pouvaient se faire
> bien plus rapidement en négligeant les 8 bits de poids fort du

> bus d'adresse. Bien pratique en asm/superviser, mais diabolique

> à gérer en C ;)

La liste n'avait nulle vocation a etre exhaustive.

[Marc]

Alexandre Bacquart wrote:

> On 12/03/2012 12:43 AM, Marc Espie wrote:
>> -O0 fait parfois des non-optimisations pas raisonnables du tout, comme
>> de deposer des zeros dans les variables non initialisees.
>>
>> (je crois que ca a finalement ete corrige en 4.x)
>

> Ouf ! Il faudrait m�me une option pour y fiche des valeurs al�atoires

> (autre que 0). Ca existe ?

Dans d'autres compilateurs, oui.