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 :)
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 :)
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 :)
Taurre é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.
Taurre <jerome.frgacic@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.
Taurre é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.
Erwan David writes:Taurre é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.
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).
Erwan David <erwan@rail.eu.org> writes:
Taurre <jerome.frgacic@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.
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).
Erwan David writes:Taurre é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.
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).
Jean-Marc Bourguet é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.
Jean-Marc Bourguet <jm@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.
Jean-Marc Bourguet é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.
In article ,
Erwan David wrote:Jean-Marc Bourguet é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.
In article <m2a9y9vgwx.fsf@rail.eu.org>,
Erwan David <erwan@rail.eu.org> wrote:
Jean-Marc Bourguet <jm@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.
In article ,
Erwan David wrote:Jean-Marc Bourguet é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.
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 sta ndard.
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 sta ndard.
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 sta ndard.
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).
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).
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).
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) ?
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) ?
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) ?
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) ?
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) ?
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) ?
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) ?
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) ?
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) ?