C'est vrai puisque ça peut référer à l'identificateur (portée) et un objet (durée)
Il faut distinguer la classe d'allocation mémoire (auto, static, extern, const, etc.)
const n'est pas une classe de mémorisation.
Si, c'est une classe de mémorisation puisqu'un (bon) compilateur la traiter différemment en l'allouant en mémoire non écrivible. Typiquement, sur une machine à segments mémoire, les variables const seront allouées dans un segment "unwritable".
Ah ? Et comment faire avec ce code:
#include <stdlib.h> void foo(){ const int l= rand(); }
Marc Boyer -- Au XXIème siècle, notre projet de société s'est réduit à un projet économique...
On 2009-02-03, Wykaaa <wykaaa@yahoo.fr> wrote:
candide a écrit :
Wykaaa a écrit :
Et pour cause car c'est ambigu.
C'est vrai puisque ça peut référer à l'identificateur (portée) et un objet (durée)
Il faut distinguer la classe d'allocation mémoire (auto, static, extern,
const, etc.)
const n'est pas une classe de mémorisation.
Si, c'est une classe de mémorisation puisqu'un (bon) compilateur la
traiter différemment en l'allouant en mémoire non écrivible.
Typiquement, sur une machine à segments mémoire, les variables const
seront allouées dans un segment "unwritable".
Ah ? Et comment faire avec ce code:
#include <stdlib.h>
void foo(){
const int l= rand();
}
Marc Boyer
--
Au XXIème siècle, notre projet de société s'est réduit
à un projet économique...
C'est vrai puisque ça peut référer à l'identificateur (portée) et un objet (durée)
Il faut distinguer la classe d'allocation mémoire (auto, static, extern, const, etc.)
const n'est pas une classe de mémorisation.
Si, c'est une classe de mémorisation puisqu'un (bon) compilateur la traiter différemment en l'allouant en mémoire non écrivible. Typiquement, sur une machine à segments mémoire, les variables const seront allouées dans un segment "unwritable".
Ah ? Et comment faire avec ce code:
#include <stdlib.h> void foo(){ const int l= rand(); }
Marc Boyer -- Au XXIème siècle, notre projet de société s'est réduit à un projet économique...
Wykaaa
Marc Boyer a écrit :
On 2009-02-03, Wykaaa wrote:
candide a écrit :
Wykaaa a écrit :
Et pour cause car c'est ambigu.
C'est vrai puisque ça peut référer à l'identificateur (portée) et un objet (durée)
Il faut distinguer la classe d'allocation mémoire (auto, static, extern, const, etc.)
const n'est pas une classe de mémorisation.
Si, c'est une classe de mémorisation puisqu'un (bon) compilateur la traiter différemment en l'allouant en mémoire non écrivible. Typiquement, sur une machine à segments mémoire, les variables const seront allouées dans un segment "unwritable".
Ah ? Et comment faire avec ce code:
#include <stdlib.h> void foo(){ const int l= rand(); }
Marc Boyer
C'est une const auto. Elle sera allouée à chaque entrée dans la fonction et désallouée en sortie dans une zone non écrivible.
Marc Boyer a écrit :
On 2009-02-03, Wykaaa <wykaaa@yahoo.fr> wrote:
candide a écrit :
Wykaaa a écrit :
Et pour cause car c'est ambigu.
C'est vrai puisque ça peut référer à l'identificateur (portée) et un objet (durée)
Il faut distinguer la classe d'allocation mémoire (auto, static, extern,
const, etc.)
const n'est pas une classe de mémorisation.
Si, c'est une classe de mémorisation puisqu'un (bon) compilateur la
traiter différemment en l'allouant en mémoire non écrivible.
Typiquement, sur une machine à segments mémoire, les variables const
seront allouées dans un segment "unwritable".
Ah ? Et comment faire avec ce code:
#include <stdlib.h>
void foo(){
const int l= rand();
}
Marc Boyer
C'est une const auto. Elle sera allouée à chaque entrée dans la fonction
et désallouée en sortie dans une zone non écrivible.
C'est vrai puisque ça peut référer à l'identificateur (portée) et un objet (durée)
Il faut distinguer la classe d'allocation mémoire (auto, static, extern, const, etc.)
const n'est pas une classe de mémorisation.
Si, c'est une classe de mémorisation puisqu'un (bon) compilateur la traiter différemment en l'allouant en mémoire non écrivible. Typiquement, sur une machine à segments mémoire, les variables const seront allouées dans un segment "unwritable".
Ah ? Et comment faire avec ce code:
#include <stdlib.h> void foo(){ const int l= rand(); }
Marc Boyer
C'est une const auto. Elle sera allouée à chaque entrée dans la fonction et désallouée en sortie dans une zone non écrivible.
Marc Boyer
On 2009-02-04, Wykaaa wrote:
Marc Boyer a écrit :
On 2009-02-03, Wykaaa wrote:
candide a écrit :
Wykaaa a écrit :
Et pour cause car c'est ambigu.
C'est vrai puisque ça peut référer à l'identificateur (portée) et un objet (durée)
Il faut distinguer la classe d'allocation mémoire (auto, static, extern, const, etc.)
const n'est pas une classe de mémorisation.
Si, c'est une classe de mémorisation puisqu'un (bon) compilateur la traiter différemment en l'allouant en mémoire non écrivible. Typiquement, sur une machine à segments mémoire, les variables const seront allouées dans un segment "unwritable".
Ah ? Et comment faire avec ce code:
#include <stdlib.h> void foo(){ const int l= rand(); }
C'est une const auto. Elle sera allouée à chaque entrée dans la fonction et désallouée en sortie dans une zone non écrivible.
Hum. Les OS ont du pas mal changer alors. Moi, j'en était resté au fait que c'était une page complète qui avait l'attribut rw/r, et aller allouer toute une page pour y mettre 32-64 bits... Sans parler du fait qu'on aimait bien allouer ce genre de chose sur une pile... Et se trainer deux piles, une de var const, une de var non const... On pourrait aussi faire sauter l'attribut read-only de la page, aller y allouer l avec sa valeur initiale, remettre l'attribut read-only...
Ca me semble bien compliqué tout ça...
Marc Boyer -- Au XXIème siècle, notre projet de société s'est réduit à un projet économique...
On 2009-02-04, Wykaaa <wykaaa@yahoo.fr> wrote:
Marc Boyer a écrit :
On 2009-02-03, Wykaaa <wykaaa@yahoo.fr> wrote:
candide a écrit :
Wykaaa a écrit :
Et pour cause car c'est ambigu.
C'est vrai puisque ça peut référer à l'identificateur (portée) et un objet (durée)
Il faut distinguer la classe d'allocation mémoire (auto, static, extern,
const, etc.)
const n'est pas une classe de mémorisation.
Si, c'est une classe de mémorisation puisqu'un (bon) compilateur la
traiter différemment en l'allouant en mémoire non écrivible.
Typiquement, sur une machine à segments mémoire, les variables const
seront allouées dans un segment "unwritable".
Ah ? Et comment faire avec ce code:
#include <stdlib.h>
void foo(){
const int l= rand();
}
C'est une const auto. Elle sera allouée à chaque entrée dans la fonction
et désallouée en sortie dans une zone non écrivible.
Hum. Les OS ont du pas mal changer alors.
Moi, j'en était resté au fait que c'était une page complète
qui avait l'attribut rw/r, et aller allouer toute une page pour
y mettre 32-64 bits... Sans parler du fait qu'on aimait bien
allouer ce genre de chose sur une pile... Et se trainer deux
piles, une de var const, une de var non const...
On pourrait aussi faire sauter l'attribut read-only de
la page, aller y allouer l avec sa valeur initiale,
remettre l'attribut read-only...
Ca me semble bien compliqué tout ça...
Marc Boyer
--
Au XXIème siècle, notre projet de société s'est réduit
à un projet économique...
C'est vrai puisque ça peut référer à l'identificateur (portée) et un objet (durée)
Il faut distinguer la classe d'allocation mémoire (auto, static, extern, const, etc.)
const n'est pas une classe de mémorisation.
Si, c'est une classe de mémorisation puisqu'un (bon) compilateur la traiter différemment en l'allouant en mémoire non écrivible. Typiquement, sur une machine à segments mémoire, les variables const seront allouées dans un segment "unwritable".
Ah ? Et comment faire avec ce code:
#include <stdlib.h> void foo(){ const int l= rand(); }
C'est une const auto. Elle sera allouée à chaque entrée dans la fonction et désallouée en sortie dans une zone non écrivible.
Hum. Les OS ont du pas mal changer alors. Moi, j'en était resté au fait que c'était une page complète qui avait l'attribut rw/r, et aller allouer toute une page pour y mettre 32-64 bits... Sans parler du fait qu'on aimait bien allouer ce genre de chose sur une pile... Et se trainer deux piles, une de var const, une de var non const... On pourrait aussi faire sauter l'attribut read-only de la page, aller y allouer l avec sa valeur initiale, remettre l'attribut read-only...
Ca me semble bien compliqué tout ça...
Marc Boyer -- Au XXIème siècle, notre projet de société s'est réduit à un projet économique...
Wykaaa
Marc Boyer a écrit :
On 2009-02-04, Wykaaa wrote:
Marc Boyer a écrit :
On 2009-02-03, Wykaaa wrote:
candide a écrit :
Wykaaa a écrit :
Et pour cause car c'est ambigu.
C'est vrai puisque ça peut référer à l'identificateur (portée) et un objet (durée)
Il faut distinguer la classe d'allocation mémoire (auto, static, extern, const, etc.)
const n'est pas une classe de mémorisation.
Si, c'est une classe de mémorisation puisqu'un (bon) compilateur la traiter différemment en l'allouant en mémoire non écrivible. Typiquement, sur une machine à segments mémoire, les variables const seront allouées dans un segment "unwritable".
Ah ? Et comment faire avec ce code:
#include <stdlib.h> void foo(){ const int l= rand(); }
C'est une const auto. Elle sera allouée à chaque entrée dans la fonction et désallouée en sortie dans une zone non écrivible.
Hum. Les OS ont du pas mal changer alors. Moi, j'en était resté au fait que c'était une page complète qui avait l'attribut rw/r, et aller allouer toute une page pour y mettre 32-64 bits... Sans parler du fait qu'on aimait bien allouer ce genre de chose sur une pile... Et se trainer deux piles, une de var const, une de var non const... On pourrait aussi faire sauter l'attribut read-only de la page, aller y allouer l avec sa valeur initiale, remettre l'attribut read-only...
Ca me semble bien compliqué tout ça...
Marc Boyer
Ce n'est pas une obligation de le faire mais c'est ce que devrait faire un compilateur si la machine cible (architecture et jeu d'instructions) le permet.
Marc Boyer a écrit :
On 2009-02-04, Wykaaa <wykaaa@yahoo.fr> wrote:
Marc Boyer a écrit :
On 2009-02-03, Wykaaa <wykaaa@yahoo.fr> wrote:
candide a écrit :
Wykaaa a écrit :
Et pour cause car c'est ambigu.
C'est vrai puisque ça peut référer à l'identificateur (portée) et un objet (durée)
Il faut distinguer la classe d'allocation mémoire (auto, static, extern,
const, etc.)
const n'est pas une classe de mémorisation.
Si, c'est une classe de mémorisation puisqu'un (bon) compilateur la
traiter différemment en l'allouant en mémoire non écrivible.
Typiquement, sur une machine à segments mémoire, les variables const
seront allouées dans un segment "unwritable".
Ah ? Et comment faire avec ce code:
#include <stdlib.h>
void foo(){
const int l= rand();
}
C'est une const auto. Elle sera allouée à chaque entrée dans la fonction
et désallouée en sortie dans une zone non écrivible.
Hum. Les OS ont du pas mal changer alors.
Moi, j'en était resté au fait que c'était une page complète
qui avait l'attribut rw/r, et aller allouer toute une page pour
y mettre 32-64 bits... Sans parler du fait qu'on aimait bien
allouer ce genre de chose sur une pile... Et se trainer deux
piles, une de var const, une de var non const...
On pourrait aussi faire sauter l'attribut read-only de
la page, aller y allouer l avec sa valeur initiale,
remettre l'attribut read-only...
Ca me semble bien compliqué tout ça...
Marc Boyer
Ce n'est pas une obligation de le faire mais c'est ce que devrait faire
un compilateur si la machine cible (architecture et jeu d'instructions)
le permet.
C'est vrai puisque ça peut référer à l'identificateur (portée) et un objet (durée)
Il faut distinguer la classe d'allocation mémoire (auto, static, extern, const, etc.)
const n'est pas une classe de mémorisation.
Si, c'est une classe de mémorisation puisqu'un (bon) compilateur la traiter différemment en l'allouant en mémoire non écrivible. Typiquement, sur une machine à segments mémoire, les variables const seront allouées dans un segment "unwritable".
Ah ? Et comment faire avec ce code:
#include <stdlib.h> void foo(){ const int l= rand(); }
C'est une const auto. Elle sera allouée à chaque entrée dans la fonction et désallouée en sortie dans une zone non écrivible.
Hum. Les OS ont du pas mal changer alors. Moi, j'en était resté au fait que c'était une page complète qui avait l'attribut rw/r, et aller allouer toute une page pour y mettre 32-64 bits... Sans parler du fait qu'on aimait bien allouer ce genre de chose sur une pile... Et se trainer deux piles, une de var const, une de var non const... On pourrait aussi faire sauter l'attribut read-only de la page, aller y allouer l avec sa valeur initiale, remettre l'attribut read-only...
Ca me semble bien compliqué tout ça...
Marc Boyer
Ce n'est pas une obligation de le faire mais c'est ce que devrait faire un compilateur si la machine cible (architecture et jeu d'instructions) le permet.
espie
In article <49897dd5$0$9392$, Wykaaa wrote:
Ce n'est pas une obligation de le faire mais c'est ce que devrait faire un compilateur si la machine cible (architecture et jeu d'instructions) le permet.
La sur le coup, je donne raison a Marc Boyer. La plupart des architectures que je connais supportent simplement une seule pile, et il n'y a pas possibilite de marquer facilement une adresse de cette pile comme non-ecrivable.
Le seul cas ou un compilateur va effectivement fabriquer des constantes, c'est s'il est suffisamment doue pour determiner qu'il s'agit d'une fonction "finale" (leaf function ? comment traduire ?)... et encore. faudra un coup d'appel systeme pour marquer la zone comme non-ecrivable.
Vu l'environnement dans lequel je bosse (OpenBSD), je suis assez bien place pour savoir que la protection en lecture a un cout, et que mettre en place plein de zones avec des attributs differents egalement: c'est un sacre bazar pour faire marcher des bibliotheques partagees avec le maximum de chose en read-only, par exemple, entre les zones ou l'editeur de liens dynamique doit avoir acces, et les contraintes de distance entre blocs de code... et tout mprotect coute cher.
In article <49897dd5$0$9392$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Ce n'est pas une obligation de le faire mais c'est ce que devrait faire
un compilateur si la machine cible (architecture et jeu d'instructions)
le permet.
La sur le coup, je donne raison a Marc Boyer.
La plupart des architectures que je connais supportent simplement une seule
pile, et il n'y a pas possibilite de marquer facilement une adresse de cette
pile comme non-ecrivable.
Le seul cas ou un compilateur va effectivement fabriquer des constantes,
c'est s'il est suffisamment doue pour determiner qu'il s'agit d'une fonction
"finale" (leaf function ? comment traduire ?)... et encore. faudra un coup
d'appel systeme pour marquer la zone comme non-ecrivable.
Vu l'environnement dans lequel je bosse (OpenBSD), je suis assez bien place
pour savoir que la protection en lecture a un cout, et que mettre en place
plein de zones avec des attributs differents egalement: c'est un sacre
bazar pour faire marcher des bibliotheques partagees avec le maximum de
chose en read-only, par exemple, entre les zones ou l'editeur de liens
dynamique doit avoir acces, et les contraintes de distance entre blocs
de code... et tout mprotect coute cher.
Ce n'est pas une obligation de le faire mais c'est ce que devrait faire un compilateur si la machine cible (architecture et jeu d'instructions) le permet.
La sur le coup, je donne raison a Marc Boyer. La plupart des architectures que je connais supportent simplement une seule pile, et il n'y a pas possibilite de marquer facilement une adresse de cette pile comme non-ecrivable.
Le seul cas ou un compilateur va effectivement fabriquer des constantes, c'est s'il est suffisamment doue pour determiner qu'il s'agit d'une fonction "finale" (leaf function ? comment traduire ?)... et encore. faudra un coup d'appel systeme pour marquer la zone comme non-ecrivable.
Vu l'environnement dans lequel je bosse (OpenBSD), je suis assez bien place pour savoir que la protection en lecture a un cout, et que mettre en place plein de zones avec des attributs differents egalement: c'est un sacre bazar pour faire marcher des bibliotheques partagees avec le maximum de chose en read-only, par exemple, entre les zones ou l'editeur de liens dynamique doit avoir acces, et les contraintes de distance entre blocs de code... et tout mprotect coute cher.
Wykaaa
Marc Espie a écrit :
In article <49897dd5$0$9392$, Wykaaa wrote:
Ce n'est pas une obligation de le faire mais c'est ce que devrait faire un compilateur si la machine cible (architecture et jeu d'instructions) le permet.
La sur le coup, je donne raison a Marc Boyer. La plupart des architectures que je connais supportent simplement une seule pile, et il n'y a pas possibilite de marquer facilement une adresse de cette pile comme non-ecrivable.
Le seul cas ou un compilateur va effectivement fabriquer des constantes, c'est s'il est suffisamment doue pour determiner qu'il s'agit d'une fonction "finale" (leaf function ? comment traduire ?)... et encore. faudra un coup d'appel systeme pour marquer la zone comme non-ecrivable.
Vu l'environnement dans lequel je bosse (OpenBSD), je suis assez bien place pour savoir que la protection en lecture a un cout, et que mettre en place plein de zones avec des attributs differents egalement: c'est un sacre bazar pour faire marcher des bibliotheques partagees avec le maximum de chose en read-only, par exemple, entre les zones ou l'editeur de liens dynamique doit avoir acces, et les contraintes de distance entre blocs de code... et tout mprotect coute cher.
Je suis entièrement d'accord avec toi. Je n'ai peut-être pas été assez explicite mais quand je disais "si la machine cible (architecture et jeu d'instructions) le permet", cela sous-entendait, implicitement, modulo des problèmes de coûts. J'ai eu la chance de faire un compilateur C pour une machine cible au "décor interne" très riche qui permettait ce genre de chose sans que cela soit à un coût prohibitif.
Marc Espie a écrit :
In article <49897dd5$0$9392$ba4acef3@news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:
Ce n'est pas une obligation de le faire mais c'est ce que devrait faire
un compilateur si la machine cible (architecture et jeu d'instructions)
le permet.
La sur le coup, je donne raison a Marc Boyer.
La plupart des architectures que je connais supportent simplement une seule
pile, et il n'y a pas possibilite de marquer facilement une adresse de cette
pile comme non-ecrivable.
Le seul cas ou un compilateur va effectivement fabriquer des constantes,
c'est s'il est suffisamment doue pour determiner qu'il s'agit d'une fonction
"finale" (leaf function ? comment traduire ?)... et encore. faudra un coup
d'appel systeme pour marquer la zone comme non-ecrivable.
Vu l'environnement dans lequel je bosse (OpenBSD), je suis assez bien place
pour savoir que la protection en lecture a un cout, et que mettre en place
plein de zones avec des attributs differents egalement: c'est un sacre
bazar pour faire marcher des bibliotheques partagees avec le maximum de
chose en read-only, par exemple, entre les zones ou l'editeur de liens
dynamique doit avoir acces, et les contraintes de distance entre blocs
de code... et tout mprotect coute cher.
Je suis entièrement d'accord avec toi.
Je n'ai peut-être pas été assez explicite mais quand je disais "si la
machine cible (architecture et jeu d'instructions) le permet", cela
sous-entendait, implicitement, modulo des problèmes de coûts.
J'ai eu la chance de faire un compilateur C pour une machine cible au
"décor interne" très riche qui permettait ce genre de chose sans que
cela soit à un coût prohibitif.
Ce n'est pas une obligation de le faire mais c'est ce que devrait faire un compilateur si la machine cible (architecture et jeu d'instructions) le permet.
La sur le coup, je donne raison a Marc Boyer. La plupart des architectures que je connais supportent simplement une seule pile, et il n'y a pas possibilite de marquer facilement une adresse de cette pile comme non-ecrivable.
Le seul cas ou un compilateur va effectivement fabriquer des constantes, c'est s'il est suffisamment doue pour determiner qu'il s'agit d'une fonction "finale" (leaf function ? comment traduire ?)... et encore. faudra un coup d'appel systeme pour marquer la zone comme non-ecrivable.
Vu l'environnement dans lequel je bosse (OpenBSD), je suis assez bien place pour savoir que la protection en lecture a un cout, et que mettre en place plein de zones avec des attributs differents egalement: c'est un sacre bazar pour faire marcher des bibliotheques partagees avec le maximum de chose en read-only, par exemple, entre les zones ou l'editeur de liens dynamique doit avoir acces, et les contraintes de distance entre blocs de code... et tout mprotect coute cher.
Je suis entièrement d'accord avec toi. Je n'ai peut-être pas été assez explicite mais quand je disais "si la machine cible (architecture et jeu d'instructions) le permet", cela sous-entendait, implicitement, modulo des problèmes de coûts. J'ai eu la chance de faire un compilateur C pour une machine cible au "décor interne" très riche qui permettait ce genre de chose sans que cela soit à un coût prohibitif.
Antoine Leca
Le 04/02/2009 11:24, Wykaaa écrivit :
Marc Boyer a écrit :
Ah ? Et comment faire avec ce code:
#include <stdlib.h> void foo(){ const int l= rand(); }
C'est une const auto. Elle sera allouée à chaque entrée dans la fonction
Oui
et désallouée en sortie
Je ne sais pas ce que cela veut dire en C.
> dans une zone non écrivible.
M'étonnerait qu'il y ait beaucoup de compilateurs qui se donne la peine de faire cela (déprotéger la zone, écrire la valeur au moment de l'allocation, reprotéger ; et au prochain appel on recommence).
Il est plus probable que l'objet (ou même seulement le nom) soit marqué «const» au niveau des tables internes du compilateur (ce qui permet d'injurier autant que faire se veut le programmeur), mais que du point de vue externe tout se passe comme si l'objet était normal.
D'un autre côté, cela c'est la cuisine... Officiellement, il est possible de faire ce que tu dis.
Antoine
Le 04/02/2009 11:24, Wykaaa écrivit :
Marc Boyer a écrit :
Ah ? Et comment faire avec ce code:
#include <stdlib.h>
void foo(){
const int l= rand();
}
C'est une const auto. Elle sera allouée à chaque entrée dans la fonction
Oui
et désallouée en sortie
Je ne sais pas ce que cela veut dire en C.
> dans une zone non écrivible.
M'étonnerait qu'il y ait beaucoup de compilateurs qui se donne la peine
de faire cela (déprotéger la zone, écrire la valeur au moment de
l'allocation, reprotéger ; et au prochain appel on recommence).
Il est plus probable que l'objet (ou même seulement le nom) soit marqué
«const» au niveau des tables internes du compilateur (ce qui permet
d'injurier autant que faire se veut le programmeur), mais que du point
de vue externe tout se passe comme si l'objet était normal.
D'un autre côté, cela c'est la cuisine... Officiellement, il est
possible de faire ce que tu dis.
#include <stdlib.h> void foo(){ const int l= rand(); }
C'est une const auto. Elle sera allouée à chaque entrée dans la fonction
Oui
et désallouée en sortie
Je ne sais pas ce que cela veut dire en C.
> dans une zone non écrivible.
M'étonnerait qu'il y ait beaucoup de compilateurs qui se donne la peine de faire cela (déprotéger la zone, écrire la valeur au moment de l'allocation, reprotéger ; et au prochain appel on recommence).
Il est plus probable que l'objet (ou même seulement le nom) soit marqué «const» au niveau des tables internes du compilateur (ce qui permet d'injurier autant que faire se veut le programmeur), mais que du point de vue externe tout se passe comme si l'objet était normal.
D'un autre côté, cela c'est la cuisine... Officiellement, il est possible de faire ce que tu dis.
Antoine
Antoine Leca
Le 04/02/2009 13:33, Marc Espie écrivit :
[...] qu'il s'agit d'une fonction "finale" (leaf function ? comment traduire ?)...
terminale ?
Antoine
Le 04/02/2009 13:33, Marc Espie écrivit :
[...] qu'il s'agit d'une fonction "finale" (leaf function ? comment traduire ?)...
[...] qu'il s'agit d'une fonction "finale" (leaf function ? comment traduire ?)...
terminale ?
Antoine
Marc Boyer
On 2009-02-04, Wykaaa wrote:
Marc Boyer a écrit :
On 2009-02-04, Wykaaa wrote:
Marc Boyer a écrit :
On 2009-02-03, Wykaaa wrote:
Si, c'est une classe de mémorisation puisqu'un (bon) compilateur la traiter différemment en l'allouant en mémoire non écrivible. Typiquement, sur une machine à segments mémoire, les variables const seront allouées dans un segment "unwritable".
Ah ? Et comment faire avec ce code:
#include <stdlib.h> void foo(){ const int l= rand(); }
C'est une const auto. Elle sera allouée à chaque entrée dans la fonction et désallouée en sortie dans une zone non écrivible.
Hum. Les OS ont du pas mal changer alors. Moi, j'en était resté au fait que c'était une page complète qui avait l'attribut rw/r, et aller allouer toute une page pour y mettre 32-64 bits... Sans parler du fait qu'on aimait bien allouer ce genre de chose sur une pile... Et se trainer deux piles, une de var const, une de var non const... On pourrait aussi faire sauter l'attribut read-only de la page, aller y allouer l avec sa valeur initiale, remettre l'attribut read-only...
Ca me semble bien compliqué tout ça...
Ce n'est pas une obligation de le faire mais c'est ce que devrait faire un compilateur si la machine cible (architecture et jeu d'instructions) le permet.
Oui, je sais bien. C'était juste qu'avec le C, les choses sont rarement simples, et pour souligner que les règles du genre "les variables const seront allouées dans un segment unwritable" ont des contre exemples faciles.
Marc Boyer -- Au XXIème siècle, notre projet de société s'est réduit à un projet économique...
On 2009-02-04, Wykaaa <wykaaa@yahoo.fr> wrote:
Marc Boyer a écrit :
On 2009-02-04, Wykaaa <wykaaa@yahoo.fr> wrote:
Marc Boyer a écrit :
On 2009-02-03, Wykaaa <wykaaa@yahoo.fr> wrote:
Si, c'est une classe de mémorisation puisqu'un (bon) compilateur la
traiter différemment en l'allouant en mémoire non écrivible.
Typiquement, sur une machine à segments mémoire, les variables const
seront allouées dans un segment "unwritable".
Ah ? Et comment faire avec ce code:
#include <stdlib.h>
void foo(){
const int l= rand();
}
C'est une const auto. Elle sera allouée à chaque entrée dans la fonction
et désallouée en sortie dans une zone non écrivible.
Hum. Les OS ont du pas mal changer alors.
Moi, j'en était resté au fait que c'était une page complète
qui avait l'attribut rw/r, et aller allouer toute une page pour
y mettre 32-64 bits... Sans parler du fait qu'on aimait bien
allouer ce genre de chose sur une pile... Et se trainer deux
piles, une de var const, une de var non const...
On pourrait aussi faire sauter l'attribut read-only de
la page, aller y allouer l avec sa valeur initiale,
remettre l'attribut read-only...
Ca me semble bien compliqué tout ça...
Ce n'est pas une obligation de le faire mais c'est ce que devrait faire
un compilateur si la machine cible (architecture et jeu d'instructions)
le permet.
Oui, je sais bien.
C'était juste qu'avec le C, les choses sont rarement simples,
et pour souligner que les règles du genre "les variables const
seront allouées dans un segment unwritable" ont des contre exemples
faciles.
Marc Boyer
--
Au XXIème siècle, notre projet de société s'est réduit
à un projet économique...
Si, c'est une classe de mémorisation puisqu'un (bon) compilateur la traiter différemment en l'allouant en mémoire non écrivible. Typiquement, sur une machine à segments mémoire, les variables const seront allouées dans un segment "unwritable".
Ah ? Et comment faire avec ce code:
#include <stdlib.h> void foo(){ const int l= rand(); }
C'est une const auto. Elle sera allouée à chaque entrée dans la fonction et désallouée en sortie dans une zone non écrivible.
Hum. Les OS ont du pas mal changer alors. Moi, j'en était resté au fait que c'était une page complète qui avait l'attribut rw/r, et aller allouer toute une page pour y mettre 32-64 bits... Sans parler du fait qu'on aimait bien allouer ce genre de chose sur une pile... Et se trainer deux piles, une de var const, une de var non const... On pourrait aussi faire sauter l'attribut read-only de la page, aller y allouer l avec sa valeur initiale, remettre l'attribut read-only...
Ca me semble bien compliqué tout ça...
Ce n'est pas une obligation de le faire mais c'est ce que devrait faire un compilateur si la machine cible (architecture et jeu d'instructions) le permet.
Oui, je sais bien. C'était juste qu'avec le C, les choses sont rarement simples, et pour souligner que les règles du genre "les variables const seront allouées dans un segment unwritable" ont des contre exemples faciles.
Marc Boyer -- Au XXIème siècle, notre projet de société s'est réduit à un projet économique...
