Je suis à la recherche de code source d'un compilateur écrit en lex
et bison.
je voudrai avoir de la documentation sur la partie d'adressage
mémoire, sur la maniere d'implémenter l'allocation de mémoire (stack,
heap) et les structures de blocs dépendament de la machine
La dernière fois que j'en avais discuté, je tenais le même genre de raisonnement, et je m'étais fait remonter les bretelles en disant que brk/sbrk devaient être vues comme des appels au noyau, et que seuls malloc/free étaient des appels "système" (au sens OS).
Ne les appelle pas "appels système", car un appel système correspond à la section 2 du manuel.
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article <bg3fe3$bnf$1@news.cict.fr>,
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> écrit:
La dernière fois que j'en avais discuté, je tenais le même genre
de raisonnement, et je m'étais fait remonter les bretelles
en disant que brk/sbrk devaient être vues comme des appels
au noyau, et que seuls malloc/free étaient des appels "système"
(au sens OS).
Ne les appelle pas "appels système", car un appel système correspond
à la section 2 du manuel.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
La dernière fois que j'en avais discuté, je tenais le même genre de raisonnement, et je m'étais fait remonter les bretelles en disant que brk/sbrk devaient être vues comme des appels au noyau, et que seuls malloc/free étaient des appels "système" (au sens OS).
Ne les appelle pas "appels système", car un appel système correspond à la section 2 du manuel.
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Marc Boyer
In article , Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', Marc Boyer wrote:
Sur Linux, malloc/free sont dans libc, et pas dans GCC. J'ai donc tendance à considérer que c'est dans l'OS plus que dans le compilateur. Ou plante mon raisonnement ?
Linux n'est qu'un système parmi d'autres. cc et gcc ne sont que des compilateurs parmi d'autres. Aucune généralisation n'est possible. Chaque implémentation fait ce qu'elle veux, du moment que les specs sont tenues.
Avec ce type d'argument, la notion de généralisation elle même est impossible. Par rapport au standart, chaque compilateur fait comme il veut pour offrir un support sur un OS donné. Maintenant, il ne me semble pas abérant de réfléchir aux solutions communément utilisées, tout en sachant qu'il existera des implémentations de niche qui, pour une raison X ou Y font autrement.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
In article <Xns93C6B213A6D66hsnoservernet@130.133.1.4>, Emmanuel Delahaye wrote:
In 'fr.comp.lang.c', Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:
Sur Linux, malloc/free sont dans libc, et pas dans GCC.
J'ai donc tendance à considérer que c'est dans l'OS plus que
dans le compilateur. Ou plante mon raisonnement ?
Linux n'est qu'un système parmi d'autres. cc et gcc ne sont que des
compilateurs parmi d'autres. Aucune généralisation n'est possible. Chaque
implémentation fait ce qu'elle veux, du moment que les specs sont tenues.
Avec ce type d'argument, la notion de généralisation elle même
est impossible.
Par rapport au standart, chaque compilateur fait comme il veut
pour offrir un support sur un OS donné. Maintenant, il ne me
semble pas abérant de réfléchir aux solutions communément
utilisées, tout en sachant qu'il existera des implémentations
de niche qui, pour une raison X ou Y font autrement.
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
Sur Linux, malloc/free sont dans libc, et pas dans GCC. J'ai donc tendance à considérer que c'est dans l'OS plus que dans le compilateur. Ou plante mon raisonnement ?
Linux n'est qu'un système parmi d'autres. cc et gcc ne sont que des compilateurs parmi d'autres. Aucune généralisation n'est possible. Chaque implémentation fait ce qu'elle veux, du moment que les specs sont tenues.
Avec ce type d'argument, la notion de généralisation elle même est impossible. Par rapport au standart, chaque compilateur fait comme il veut pour offrir un support sur un OS donné. Maintenant, il ne me semble pas abérant de réfléchir aux solutions communément utilisées, tout en sachant qu'il existera des implémentations de niche qui, pour une raison X ou Y font autrement.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Gabriel Dos Reis
Vincent Lefevre <vincent+ writes:
| Si tu veux un autre exemple: il y a quelques années, l'installation | de base de Solaris ne comprenait pas de compilo C
c'est toujours le cas, non ? Ils ont changé de politique ?
-- Gaby
Vincent Lefevre <vincent+news@vinc17.org> writes:
| Si tu veux un autre exemple: il y a quelques années, l'installation
| de base de Solaris ne comprenait pas de compilo C
c'est toujours le cas, non ? Ils ont changé de politique ?
| Si tu veux un autre exemple: il y a quelques années, l'installation | de base de Solaris ne comprenait pas de compilo C
c'est toujours le cas, non ? Ils ont changé de politique ?
-- Gaby
Erwan David
Gabriel Dos Reis écrivait :
Pour info, GCC par exemple optimise certains appels à printf et consort. Il optimise aussi certains appels à d'autres fonctions de la bibliothèque C (genre les str* par exemple).
Il est logique qu'un compilateur C puisse optimiser les fonctions de la bibliothèque C.
-- Monde de merde
Gabriel Dos Reis <gdr@integrable-solutions.net> écrivait :
Pour info, GCC par exemple optimise certains appels à printf et consort.
Il optimise aussi certains appels à d'autres fonctions de la
bibliothèque C (genre les str* par exemple).
Il est logique qu'un compilateur C puisse optimiser les fonctions de
la bibliothèque C.
Pour info, GCC par exemple optimise certains appels à printf et consort. Il optimise aussi certains appels à d'autres fonctions de la bibliothèque C (genre les str* par exemple).
Il est logique qu'un compilateur C puisse optimiser les fonctions de la bibliothèque C.
-- Monde de merde
Marc Boyer
In article <20030728151400$, Vincent Lefevre wrote:
Dans l'article <bg3dv7$b71$, Marc Boyer écrit:
Ca n'est peut-être pas assez clair, mais j'ai pris les convolutions oratoire nécessaires il me semble pour dire que c'était "fortement probable" mais pas "certain".
Si tu veux un autre exemple: il y a quelques années, l'installation de base de Solaris ne comprenait pas de compilo C (ou en partie, en tout cas, impossible de compiler un "Hello World"). J'avais dû me plaindre aux administrateurs système pour qu'ils m'installent une version plus complète. C'est vrai qu'il existait un compilo C ici, mais le C ne doit pas être si universel que ça pour ne pas avoir de compilo en standard...
D'après mon admin système dans les années 90, c'était surtout une question de politique commerciale qu'une question technique. Si tu dois écrire un compilateur pour le langage X pour Solaris, tu prends en compte le fait qu'il existe (même payant) un compilateur C (quitte à décider de ne pas l'utiliser), non ?
Il n'y a pas d'obligation non. Mais si une platerforme (OS) l'offre, il faut une bonne raison pour ne pas l'utiliser, non ?
Il peut y avoir des raisons de rapidité. D'ailleurs, le malloc() de la libc ne se résume pas qu'à un appel système.
Tout à fait.
Sous RISC OS, une allocation par malloc ne se fait pas forcément dans le tas, mais aussi à d'autres endroits de la mémoire. D'ailleurs, il me semble que la pile (discontinue) est vue comme une partie du tas.
Il faudrait donc préciser "dynamique sur le tas"...
Précision faite quand j'ai répondu à l'OP.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
In article <20030728151400$2808@vinc17.org>, Vincent Lefevre wrote:
Dans l'article <bg3dv7$b71$2@news.cict.fr>,
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> écrit:
Ca n'est peut-être pas assez clair, mais j'ai pris les
convolutions oratoire nécessaires il me semble pour dire
que c'était "fortement probable" mais pas "certain".
Si tu veux un autre exemple: il y a quelques années, l'installation
de base de Solaris ne comprenait pas de compilo C (ou en partie, en
tout cas, impossible de compiler un "Hello World"). J'avais dû me
plaindre aux administrateurs système pour qu'ils m'installent une
version plus complète. C'est vrai qu'il existait un compilo C ici,
mais le C ne doit pas être si universel que ça pour ne pas avoir de
compilo en standard...
D'après mon admin système dans les années 90, c'était surtout
une question de politique commerciale qu'une question technique.
Si tu dois écrire un compilateur pour le langage X pour Solaris,
tu prends en compte le fait qu'il existe (même payant) un
compilateur C (quitte à décider de ne pas l'utiliser), non ?
Il n'y a pas d'obligation non.
Mais si une platerforme (OS) l'offre, il faut une bonne
raison pour ne pas l'utiliser, non ?
Il peut y avoir des raisons de rapidité. D'ailleurs, le malloc()
de la libc ne se résume pas qu'à un appel système.
Tout à fait.
Sous RISC OS, une allocation par malloc ne se fait pas forcément
dans le tas, mais aussi à d'autres endroits de la mémoire.
D'ailleurs, il me semble que la pile (discontinue) est vue
comme une partie du tas.
Il faudrait donc préciser "dynamique sur le tas"...
Précision faite quand j'ai répondu à l'OP.
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
In article <20030728151400$, Vincent Lefevre wrote:
Dans l'article <bg3dv7$b71$, Marc Boyer écrit:
Ca n'est peut-être pas assez clair, mais j'ai pris les convolutions oratoire nécessaires il me semble pour dire que c'était "fortement probable" mais pas "certain".
Si tu veux un autre exemple: il y a quelques années, l'installation de base de Solaris ne comprenait pas de compilo C (ou en partie, en tout cas, impossible de compiler un "Hello World"). J'avais dû me plaindre aux administrateurs système pour qu'ils m'installent une version plus complète. C'est vrai qu'il existait un compilo C ici, mais le C ne doit pas être si universel que ça pour ne pas avoir de compilo en standard...
D'après mon admin système dans les années 90, c'était surtout une question de politique commerciale qu'une question technique. Si tu dois écrire un compilateur pour le langage X pour Solaris, tu prends en compte le fait qu'il existe (même payant) un compilateur C (quitte à décider de ne pas l'utiliser), non ?
Il n'y a pas d'obligation non. Mais si une platerforme (OS) l'offre, il faut une bonne raison pour ne pas l'utiliser, non ?
Il peut y avoir des raisons de rapidité. D'ailleurs, le malloc() de la libc ne se résume pas qu'à un appel système.
Tout à fait.
Sous RISC OS, une allocation par malloc ne se fait pas forcément dans le tas, mais aussi à d'autres endroits de la mémoire. D'ailleurs, il me semble que la pile (discontinue) est vue comme une partie du tas.
Il faudrait donc préciser "dynamique sur le tas"...
Précision faite quand j'ai répondu à l'OP.
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Vincent Lefevre
Dans l'article , Gabriel Dos Reis écrit:
Vincent Lefevre <vincent+ writes: | Si tu veux différencier mémoire automatique et mémoire dynamique comme | tu sembles le faire, pourquoi pas. Tu as une définition *officielle* | de "mémoire automatique" et "mémoire dynamique"?
Puisque alloca n'est pas standard, tu ne veux pas une définition officielle qui s'applique à alloca, n'est-il pas ?
Donc la différenciation automatique / dynamique est propre à toi.
Autrement tu peux jeter un coup d'oeil à
6.2.4 Storage durations of objects
Ça fait référence à la *durée* de stockage et non pas à une certaine manière d'allouer la mémoire. D'ailleurs, il n'est mentionné ici nulle part le terme "dynamic", mais "static", "automatic" et "allocated". Pour moi, "automatic" et "allocated" correspondent tous deux à de la mémoire dynamique.
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Dans l'article <m3he5665sv.fsf@uniton.integrable-solutions.net>,
Gabriel Dos Reis <gdr@integrable-solutions.net> écrit:
Vincent Lefevre <vincent+news@vinc17.org> writes:
| Si tu veux différencier mémoire automatique et mémoire dynamique comme
| tu sembles le faire, pourquoi pas. Tu as une définition *officielle*
| de "mémoire automatique" et "mémoire dynamique"?
Puisque alloca n'est pas standard, tu ne veux pas une définition
officielle qui s'applique à alloca, n'est-il pas ?
Donc la différenciation automatique / dynamique est propre à toi.
Autrement tu peux jeter un coup d'oeil à
6.2.4 Storage durations of objects
Ça fait référence à la *durée* de stockage et non pas à une certaine
manière d'allouer la mémoire. D'ailleurs, il n'est mentionné ici
nulle part le terme "dynamic", mais "static", "automatic" et
"allocated". Pour moi, "automatic" et "allocated" correspondent
tous deux à de la mémoire dynamique.
--
Vincent Lefèvre <vincent@vinc17.org> - Web: <http://www.vinc17.org/> - 100%
validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International
des Jeux Mathématiques et Logiques, TETRHEX, etc.
Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Vincent Lefevre <vincent+ writes: | Si tu veux différencier mémoire automatique et mémoire dynamique comme | tu sembles le faire, pourquoi pas. Tu as une définition *officielle* | de "mémoire automatique" et "mémoire dynamique"?
Puisque alloca n'est pas standard, tu ne veux pas une définition officielle qui s'applique à alloca, n'est-il pas ?
Donc la différenciation automatique / dynamique est propre à toi.
Autrement tu peux jeter un coup d'oeil à
6.2.4 Storage durations of objects
Ça fait référence à la *durée* de stockage et non pas à une certaine manière d'allouer la mémoire. D'ailleurs, il n'est mentionné ici nulle part le terme "dynamic", mais "static", "automatic" et "allocated". Pour moi, "automatic" et "allocated" correspondent tous deux à de la mémoire dynamique.
-- Vincent Lefèvre - Web: <http://www.vinc17.org/> - 100% validated (X)HTML - Acorn Risc PC, Yellow Pig 17, Championnat International des Jeux Mathématiques et Logiques, TETRHEX, etc. Work: CR INRIA - computer arithmetic / SPACES project at LORIA
Marc Boyer
Gabriel Dos Reis wrote:
Marc Boyer writes:
| Gabriel Dos Reis wrote: | > Marc Boyer writes: | > Oui, mais ce n'est pas un exemple à multiplier. Et beaucoup de cela | > provient de la confusion. | | Ben, disons que quand on cherche à savoir comment fonctionne | un OS, GNU/Linux offre sous ces détails, alors que d'autres | préfèrent garder leurs secrets de cuisine.
Toujours est-il que je ne vois pas pourquoi cela doit être un exemple à reproduire.
Par manque d'imagination. Quand tu connais une solution qui marche, c'est le talent qui fait que tu peux en inventer une meilleure, et le talent n'est pas donné à tout le monde ;-)
| La dernière fois que j'en avais discuté, je tenais le même genre | de raisonnement, et je m'étais fait remonter les bretelles
par qui ?
Désolé, j'ai plus les noms en tête.
| en disant que brk/sbrk devaient être vues comme des appels | au noyau,
ce qui n'est pas faux.
| et que seuls malloc/free étaient des appels "système" | (au sens OS).
Là c'est du délire. Et sin(), c'est une appel au noyau ou au un appel système ? :-)
Que vient faire sin ici ?
| "For occult reasons, the default allocator is notoriously | slow. A possible reason is that it is usually implemented as | a thin wrapper aroud the C heap allocator (malloc/realloc/free). | The C heap allocator is not focused on optimizing small chunk | allocations" ($4.1, p78)
Bon ben, je n'ai plus à lui remonter les bretelles :-)
Si on ne peut plus faire confiance à des bouquins dans une série dirigée par B. Stroustrup...
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Gabriel Dos Reis wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> writes:
| Gabriel Dos Reis wrote:
| > Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> writes:
| > Oui, mais ce n'est pas un exemple à multiplier. Et beaucoup de cela
| > provient de la confusion.
|
| Ben, disons que quand on cherche à savoir comment fonctionne
| un OS, GNU/Linux offre sous ces détails, alors que d'autres
| préfèrent garder leurs secrets de cuisine.
Toujours est-il que je ne vois pas pourquoi cela doit être un exemple
à reproduire.
Par manque d'imagination. Quand tu connais une solution
qui marche, c'est le talent qui fait que tu peux en inventer
une meilleure, et le talent n'est pas donné à tout le monde ;-)
| La dernière fois que j'en avais discuté, je tenais le même genre
| de raisonnement, et je m'étais fait remonter les bretelles
par qui ?
Désolé, j'ai plus les noms en tête.
| en disant que brk/sbrk devaient être vues comme des appels
| au noyau,
ce qui n'est pas faux.
| et que seuls malloc/free étaient des appels "système"
| (au sens OS).
Là c'est du délire. Et sin(), c'est une appel au noyau ou au un appel
système ? :-)
Que vient faire sin ici ?
| "For occult reasons, the default allocator is notoriously
| slow. A possible reason is that it is usually implemented as
| a thin wrapper aroud the C heap allocator (malloc/realloc/free).
| The C heap allocator is not focused on optimizing small chunk
| allocations" ($4.1, p78)
Bon ben, je n'ai plus à lui remonter les bretelles :-)
Si on ne peut plus faire confiance à des bouquins dans
une série dirigée par B. Stroustrup...
Marc Boyer
--
Lying for having sex or lying for making war? Trust US presidents :-(
| Gabriel Dos Reis wrote: | > Marc Boyer writes: | > Oui, mais ce n'est pas un exemple à multiplier. Et beaucoup de cela | > provient de la confusion. | | Ben, disons que quand on cherche à savoir comment fonctionne | un OS, GNU/Linux offre sous ces détails, alors que d'autres | préfèrent garder leurs secrets de cuisine.
Toujours est-il que je ne vois pas pourquoi cela doit être un exemple à reproduire.
Par manque d'imagination. Quand tu connais une solution qui marche, c'est le talent qui fait que tu peux en inventer une meilleure, et le talent n'est pas donné à tout le monde ;-)
| La dernière fois que j'en avais discuté, je tenais le même genre | de raisonnement, et je m'étais fait remonter les bretelles
par qui ?
Désolé, j'ai plus les noms en tête.
| en disant que brk/sbrk devaient être vues comme des appels | au noyau,
ce qui n'est pas faux.
| et que seuls malloc/free étaient des appels "système" | (au sens OS).
Là c'est du délire. Et sin(), c'est une appel au noyau ou au un appel système ? :-)
Que vient faire sin ici ?
| "For occult reasons, the default allocator is notoriously | slow. A possible reason is that it is usually implemented as | a thin wrapper aroud the C heap allocator (malloc/realloc/free). | The C heap allocator is not focused on optimizing small chunk | allocations" ($4.1, p78)
Bon ben, je n'ai plus à lui remonter les bretelles :-)
Si on ne peut plus faire confiance à des bouquins dans une série dirigée par B. Stroustrup...
Marc Boyer -- Lying for having sex or lying for making war? Trust US presidents :-(
Richard Delorme
In article , Jean-Marc Bourguet wrote:
Marc Boyer writes:
Sur Linux, malloc/free sont dans libc, et pas dans GCC.
Sous Linux (et sous Unix en general), il y a de la confusion(*) entre la bibliotheque standard du C et les bibliotheques d'interfacage de l'OS.
Suite à de longues discussions entre OS, noyau, modules sur fcol (de mémoire), on avait finit par converger vers le fait que la libc faisait partie de ce que l'on nomme communément OS (d'ou l'appellation "GNU/Linux" pour l'OS et non juste "Linux").
Comme Susv3 (la norme Unix) impose l'existence d'un compilateur C, je ne sais pas jusqu'à quel point le compilateur C ne fait pas partie de cet OS...
-- Richard
In article <pxbbrvelo6v.fsf@news.bourguet.org>, Jean-Marc Bourguet wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> writes:
Sur Linux, malloc/free sont dans libc, et pas dans GCC.
Sous Linux (et sous Unix en general), il y a de la confusion(*) entre
la bibliotheque standard du C et les bibliotheques d'interfacage de
l'OS.
Suite à de longues discussions entre OS, noyau, modules
sur fcol (de mémoire), on avait finit par converger vers le
fait que la libc faisait partie de ce que l'on nomme
communément OS (d'ou l'appellation "GNU/Linux" pour l'OS
et non juste "Linux").
Comme Susv3 (la norme Unix) impose l'existence d'un compilateur C, je ne
sais pas jusqu'à quel point le compilateur C ne fait pas partie de cet
OS...
Sur Linux, malloc/free sont dans libc, et pas dans GCC.
Sous Linux (et sous Unix en general), il y a de la confusion(*) entre la bibliotheque standard du C et les bibliotheques d'interfacage de l'OS.
Suite à de longues discussions entre OS, noyau, modules sur fcol (de mémoire), on avait finit par converger vers le fait que la libc faisait partie de ce que l'on nomme communément OS (d'ou l'appellation "GNU/Linux" pour l'OS et non juste "Linux").
Comme Susv3 (la norme Unix) impose l'existence d'un compilateur C, je ne sais pas jusqu'à quel point le compilateur C ne fait pas partie de cet OS...
-- Richard
Gabriel Dos Reis
Vincent Lefevre <vincent+ writes:
| Dans l'article , | Gabriel Dos Reis écrit: | | > Vincent Lefevre <vincent+ writes: | > | Si tu veux différencier mémoire automatique et mémoire dynamique comme | > | tu sembles le faire, pourquoi pas. Tu as une définition *officielle* | > | de "mémoire automatique" et "mémoire dynamique"? | > | > Puisque alloca n'est pas standard, tu ne veux pas une définition | > officielle qui s'applique à alloca, n'est-il pas ? | | Donc la différenciation automatique / dynamique est propre à toi.
Non. Pour t'en apercevoir, il aurait fallu que tu lises mon message.
| > Autrement tu peux jeter un coup d'oeil à | > | > 6.2.4 Storage durations of objects | | Ça fait référence à la *durée* de stockage et non pas à une certaine | manière d'allouer la mémoire.
Tu as demandé « mémoire automatique » et « mémoire dynamique » pas allocation de telles mémoires. Pour l'allocation, il suffit de se reporter aux références qui suivaient.
| D'ailleurs, il n'est mentionné ici | nulle part le terme "dynamic", mais "static", "automatic" et | "allocated". Pour moi, "automatic" et "allocated" correspondent | tous deux à de la mémoire dynamique.
alors prépare-toi au plus grandes confusions.
La mémoire automatique, c'est ce que tu as avec les variables locales (non statiques) et les paramètres. Une telle mémoire est libérée automatiquement après exécution de l'instruction return de la fonction.
La mémoire dynamique, c'est ce que tu as avec malloc()/calloc() et consort. Mais pas alloca. Pour alloca, la mémoire est libérée automatiquement comme pour les variables automatiques.
-- Gaby
Vincent Lefevre <vincent+news@vinc17.org> writes:
| Dans l'article <m3he5665sv.fsf@uniton.integrable-solutions.net>,
| Gabriel Dos Reis <gdr@integrable-solutions.net> écrit:
|
| > Vincent Lefevre <vincent+news@vinc17.org> writes:
| > | Si tu veux différencier mémoire automatique et mémoire dynamique comme
| > | tu sembles le faire, pourquoi pas. Tu as une définition *officielle*
| > | de "mémoire automatique" et "mémoire dynamique"?
| >
| > Puisque alloca n'est pas standard, tu ne veux pas une définition
| > officielle qui s'applique à alloca, n'est-il pas ?
|
| Donc la différenciation automatique / dynamique est propre à toi.
Non. Pour t'en apercevoir, il aurait fallu que tu lises mon message.
| > Autrement tu peux jeter un coup d'oeil à
| >
| > 6.2.4 Storage durations of objects
|
| Ça fait référence à la *durée* de stockage et non pas à une certaine
| manière d'allouer la mémoire.
Tu as demandé « mémoire automatique » et « mémoire dynamique » pas
allocation de telles mémoires. Pour l'allocation, il suffit de se
reporter aux références qui suivaient.
| D'ailleurs, il n'est mentionné ici
| nulle part le terme "dynamic", mais "static", "automatic" et
| "allocated". Pour moi, "automatic" et "allocated" correspondent
| tous deux à de la mémoire dynamique.
alors prépare-toi au plus grandes confusions.
La mémoire automatique, c'est ce que tu as avec les variables locales
(non statiques) et les paramètres. Une telle mémoire est libérée
automatiquement après exécution de l'instruction return de la
fonction.
La mémoire dynamique, c'est ce que tu as avec malloc()/calloc() et consort.
Mais pas alloca. Pour alloca, la mémoire est libérée automatiquement
comme pour les variables automatiques.
| Dans l'article , | Gabriel Dos Reis écrit: | | > Vincent Lefevre <vincent+ writes: | > | Si tu veux différencier mémoire automatique et mémoire dynamique comme | > | tu sembles le faire, pourquoi pas. Tu as une définition *officielle* | > | de "mémoire automatique" et "mémoire dynamique"? | > | > Puisque alloca n'est pas standard, tu ne veux pas une définition | > officielle qui s'applique à alloca, n'est-il pas ? | | Donc la différenciation automatique / dynamique est propre à toi.
Non. Pour t'en apercevoir, il aurait fallu que tu lises mon message.
| > Autrement tu peux jeter un coup d'oeil à | > | > 6.2.4 Storage durations of objects | | Ça fait référence à la *durée* de stockage et non pas à une certaine | manière d'allouer la mémoire.
Tu as demandé « mémoire automatique » et « mémoire dynamique » pas allocation de telles mémoires. Pour l'allocation, il suffit de se reporter aux références qui suivaient.
| D'ailleurs, il n'est mentionné ici | nulle part le terme "dynamic", mais "static", "automatic" et | "allocated". Pour moi, "automatic" et "allocated" correspondent | tous deux à de la mémoire dynamique.
alors prépare-toi au plus grandes confusions.
La mémoire automatique, c'est ce que tu as avec les variables locales (non statiques) et les paramètres. Une telle mémoire est libérée automatiquement après exécution de l'instruction return de la fonction.
La mémoire dynamique, c'est ce que tu as avec malloc()/calloc() et consort. Mais pas alloca. Pour alloca, la mémoire est libérée automatiquement comme pour les variables automatiques.
-- Gaby
Gabriel Dos Reis
Marc Boyer writes:
| >| et que seuls malloc/free étaient des appels "système" | >| (au sens OS). | > | > Là c'est du délire. Et sin(), c'est une appel au noyau ou au un appel | > système ? :-) | | Que vient faire sin ici ?
C'est une fonction qui fait partie de la bibliothèque C, tout comme malloc/free.
-- gaby
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> writes:
| >| et que seuls malloc/free étaient des appels "système"
| >| (au sens OS).
| >
| > Là c'est du délire. Et sin(), c'est une appel au noyau ou au un appel
| > système ? :-)
|
| Que vient faire sin ici ?
C'est une fonction qui fait partie de la bibliothèque C, tout comme
malloc/free.
| >| et que seuls malloc/free étaient des appels "système" | >| (au sens OS). | > | > Là c'est du délire. Et sin(), c'est une appel au noyau ou au un appel | > système ? :-) | | Que vient faire sin ici ?
C'est une fonction qui fait partie de la bibliothèque C, tout comme malloc/free.
