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
| Marc Boyer writes: | | > 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 | | Et pourquoi donc l'implementation de printf doit faire partie de l'OS? | C'est bien de la confusion des genres... si tu veux passer a C99, il | te faut non seulement un compilateur mais aussi un OS adequat.
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).
| > PS: En cas de suite, je te laisse choisir un fu2 | > vers fco.unix, fco.linux ou autre | | Copie et suivit sur fcou, rien de specifique a linux la-dedans.
Je n'ai pas fait le suivi parce que je crois qu'il y a encore du contenu C ayant sa place sur fclc.
-- Gaby
Jean-Marc Bourguet <jm@bourguet.org> writes:
| Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> writes:
|
| > 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
|
| Et pourquoi donc l'implementation de printf doit faire partie de l'OS?
| C'est bien de la confusion des genres... si tu veux passer a C99, il
| te faut non seulement un compilateur mais aussi un OS adequat.
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).
| > PS: En cas de suite, je te laisse choisir un fu2
| > vers fco.unix, fco.linux ou autre
|
| Copie et suivit sur fcou, rien de specifique a linux la-dedans.
Je n'ai pas fait le suivi parce que je crois qu'il y a encore du
contenu C ayant sa place sur fclc.
| Marc Boyer writes: | | > 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 | | Et pourquoi donc l'implementation de printf doit faire partie de l'OS? | C'est bien de la confusion des genres... si tu veux passer a C99, il | te faut non seulement un compilateur mais aussi un OS adequat.
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).
| > PS: En cas de suite, je te laisse choisir un fu2 | > vers fco.unix, fco.linux ou autre | | Copie et suivit sur fcou, rien de specifique a linux la-dedans.
Je n'ai pas fait le suivi parce que je crois qu'il y a encore du contenu C ayant sa place sur fclc.
-- Gaby
Jean-Marc Bourguet
Gabriel Dos Reis writes:
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).
Genial.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Gabriel Dos Reis <gdr@integrable-solutions.net> writes:
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).
Genial.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
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).
Genial.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Jean-Marc Bourguet
Vincent Lefevre <vincent+ writes:
Dans l'article , Erwan David écrit:
Marc Boyer écrivait :
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 ?
Que libc c'est la lib du C, c'est pas une partie de l'OS.
Tout dépend de comment on définit un OS: si c'est juste le noyau ou le noyau + d'autres choses.
C'est le noyau + d'autres choses. Mais le probleme est que la libc contient des choses qui logiquement font partie de l'OS (l'implementation de write par exemple) et d'autres qui n'en font pas (l'implementation de printf par exemple). C'est pourquoi je parle de confusion.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Vincent Lefevre <vincent+news@vinc17.org> writes:
Dans l'article <85lluiiumu.fsf@bretagne.rail.eu.org>,
Erwan David <erwan@rail.eu.org> écrit:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> écrivait :
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 ?
Que libc c'est la lib du C, c'est pas une partie de l'OS.
Tout dépend de comment on définit un OS: si c'est juste le noyau
ou le noyau + d'autres choses.
C'est le noyau + d'autres choses. Mais le probleme est que la libc
contient des choses qui logiquement font partie de l'OS
(l'implementation de write par exemple) et d'autres qui n'en font pas
(l'implementation de printf par exemple). C'est pourquoi je parle de
confusion.
A+
--
Jean-Marc
FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
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 ?
Que libc c'est la lib du C, c'est pas une partie de l'OS.
Tout dépend de comment on définit un OS: si c'est juste le noyau ou le noyau + d'autres choses.
C'est le noyau + d'autres choses. Mais le probleme est que la libc contient des choses qui logiquement font partie de l'OS (l'implementation de write par exemple) et d'autres qui n'en font pas (l'implementation de printf par exemple). C'est pourquoi je parle de confusion.
A+
-- Jean-Marc FAQ de fclc: http://www.isty-info.uvsq.fr/~rumeau/fclc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Emmanuel Delahaye
In 'fr.comp.lang.c', Vincent Lefevre <vincent+ wrote:
Dans l'article , Gabriel Dos Reis écrit:
Ce que fait alloca est plus proche de la mémoire automatique que de la mémoire dynamique.
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"?
En tout cas, ça concerne certainement la durée de vie. Pas question de retourner une adresse données par alloca. Elle est aussi détruite que celle d'une variable locale.
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Vincent Lefevre <vincent+news@vinc17.org> wrote:
Dans l'article <m34r167lhd.fsf@uniton.integrable-solutions.net>,
Gabriel Dos Reis <gdr@integrable-solutions.net> écrit:
Ce que fait alloca est plus proche de la mémoire automatique que de la
mémoire dynamique.
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"?
En tout cas, ça concerne certainement la durée de vie. Pas question de
retourner une adresse données par alloca. Elle est aussi détruite que celle
d'une variable locale.
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Vincent Lefevre <vincent+ wrote:
Dans l'article , Gabriel Dos Reis écrit:
Ce que fait alloca est plus proche de la mémoire automatique que de la mémoire dynamique.
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"?
En tout cas, ça concerne certainement la durée de vie. Pas question de retourner une adresse données par alloca. Elle est aussi détruite que celle d'une variable locale.
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Vincent Lefevre
Dans l'article <bg3dv7$b71$, Marc Boyer écrit:
In article <20030728142800$, Vincent Lefevre wrote:
Dans l'article <bg30eo$8le$, Marc Boyer écrit:
Oui et non. Oui, si on considère que le C est un langage "comme les autres". Non dans le sens ou le C est quasiment "universel", et que, hormis cas très spécifique, si tu as à écrire un compilo (autre qu'assembleur) sur une platerforme donnée, il y a de *très* fortes chances qu'il existe déjà un compilateur C.
C'est faux pour les Psion (sous EPOC), malheureusement (et c'est une des raisons pour lesquelles je n'utilise quasiment plus le mien).
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...
Je ne sais pas ce qui se passe en pratique pour l'ensemble des compilateurs. Mais il n'y a pas de raison pour passer l'allocation dynamique à des éléments extérieurs.
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.
J'ai fait un glissement de "dynamique sur le tas" à "dynamique" en pensant que le contexte était clair. Si cela ne l'était pas, je refais la précision.
OK. Mais noter qu'avec une même interface (e.g. celle de GMP), l'allocation peut se faire soit dans le tas, soit dans la pile.
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"...
-- 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 <bg3dv7$b71$2@news.cict.fr>,
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> écrit:
In article <20030728142800$46b1@vinc17.org>, Vincent Lefevre wrote:
Dans l'article <bg30eo$8le$2@news.cict.fr>,
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> écrit:
Oui et non. Oui, si on considère que le C est un langage
"comme les autres". Non dans le sens ou le C est quasiment
"universel", et que, hormis cas très spécifique, si tu as à
écrire un compilo (autre qu'assembleur) sur une platerforme
donnée, il y a de *très* fortes chances qu'il existe déjà
un compilateur C.
C'est faux pour les Psion (sous EPOC), malheureusement (et c'est
une des raisons pour lesquelles je n'utilise quasiment plus le
mien).
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...
Je ne sais pas ce qui se passe en pratique pour l'ensemble des
compilateurs. Mais il n'y a pas de raison pour passer l'allocation
dynamique à des éléments extérieurs.
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.
J'ai fait un glissement de "dynamique sur le tas" à "dynamique"
en pensant que le contexte était clair. Si cela ne l'était pas,
je refais la précision.
OK. Mais noter qu'avec une même interface (e.g. celle de GMP),
l'allocation peut se faire soit dans le tas, soit dans la pile.
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"...
--
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
In article <20030728142800$, Vincent Lefevre wrote:
Dans l'article <bg30eo$8le$, Marc Boyer écrit:
Oui et non. Oui, si on considère que le C est un langage "comme les autres". Non dans le sens ou le C est quasiment "universel", et que, hormis cas très spécifique, si tu as à écrire un compilo (autre qu'assembleur) sur une platerforme donnée, il y a de *très* fortes chances qu'il existe déjà un compilateur C.
C'est faux pour les Psion (sous EPOC), malheureusement (et c'est une des raisons pour lesquelles je n'utilise quasiment plus le mien).
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...
Je ne sais pas ce qui se passe en pratique pour l'ensemble des compilateurs. Mais il n'y a pas de raison pour passer l'allocation dynamique à des éléments extérieurs.
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.
J'ai fait un glissement de "dynamique sur le tas" à "dynamique" en pensant que le contexte était clair. Si cela ne l'était pas, je refais la précision.
OK. Mais noter qu'avec une même interface (e.g. celle de GMP), l'allocation peut se faire soit dans le tas, soit dans la pile.
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"...
-- 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
Emmanuel Delahaye
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.
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
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.
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
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.
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Emmanuel Delahaye
In 'fr.comp.lang.c', Marc Boyer wrote:
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").
Quelle hérésie! La partie standard de la libc fait partie de l'implémentation du langage C qui est installée sur la machine.
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:
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").
Quelle hérésie! La partie standard de la libc fait partie de l'implémentation
du langage C qui est installée sur la machine.
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
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").
Quelle hérésie! La partie standard de la libc fait partie de l'implémentation du langage C qui est installée sur la machine.
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Gabriel Dos Reis
Emmanuel Delahaye writes:
| In 'fr.comp.lang.c', Vincent Lefevre <vincent+ wrote: | | > Dans l'article , | > Gabriel Dos Reis écrit: | > | >> Ce que fait alloca est plus proche de la mémoire automatique que de la | >> mémoire dynamique. | > | > 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"? | > | | En tout cas, ça concerne certainement la durée de vie. Pas question de | retourner une adresse données par alloca. Elle est aussi détruite que celle | d'une variable locale.
et ceci automatiquement, lorsque la fonction exécute un return.
-- Gaby
Emmanuel Delahaye <emdelYOURBRA@noos.fr> writes:
| In 'fr.comp.lang.c', Vincent Lefevre <vincent+news@vinc17.org> wrote:
|
| > Dans l'article <m34r167lhd.fsf@uniton.integrable-solutions.net>,
| > Gabriel Dos Reis <gdr@integrable-solutions.net> écrit:
| >
| >> Ce que fait alloca est plus proche de la mémoire automatique que de la
| >> mémoire dynamique.
| >
| > 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"?
| >
|
| En tout cas, ça concerne certainement la durée de vie. Pas question de
| retourner une adresse données par alloca. Elle est aussi détruite que celle
| d'une variable locale.
et ceci automatiquement, lorsque la fonction exécute un return.
| In 'fr.comp.lang.c', Vincent Lefevre <vincent+ wrote: | | > Dans l'article , | > Gabriel Dos Reis écrit: | > | >> Ce que fait alloca est plus proche de la mémoire automatique que de la | >> mémoire dynamique. | > | > 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"? | > | | En tout cas, ça concerne certainement la durée de vie. Pas question de | retourner une adresse données par alloca. Elle est aussi détruite que celle | d'une variable locale.
et ceci automatiquement, lorsque la fonction exécute un return.
-- Gaby
Emmanuel Delahaye
In 'fr.comp.lang.c', Vincent Lefevre <vincent+ wrote:
Dans l'article , Erwan David écrit:
Marc Boyer écrivait :
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 ?
Que libc c'est la lib du C, c'est pas une partie de l'OS.
Tout dépend de comment on définit un OS: si c'est juste le noyau ou le noyau + d'autres choses.
Je ne vois pas pourquoi l'OS serait lié à un langage particulier. C'est idiot. Y'a une libpas, aussi, une libada etc? C'est n'importe quoi.
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Vincent Lefevre <vincent+news@vinc17.org> wrote:
Dans l'article <85lluiiumu.fsf@bretagne.rail.eu.org>,
Erwan David <erwan@rail.eu.org> écrit:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> écrivait :
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 ?
Que libc c'est la lib du C, c'est pas une partie de l'OS.
Tout dépend de comment on définit un OS: si c'est juste le noyau
ou le noyau + d'autres choses.
Je ne vois pas pourquoi l'OS serait lié à un langage particulier. C'est
idiot. Y'a une libpas, aussi, une libada etc? C'est n'importe quoi.
--
-ed- emdelYOURBRA@noos.fr [remove YOURBRA before answering me]
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
<blank line>
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
In 'fr.comp.lang.c', Vincent Lefevre <vincent+ wrote:
Dans l'article , Erwan David écrit:
Marc Boyer écrivait :
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 ?
Que libc c'est la lib du C, c'est pas une partie de l'OS.
Tout dépend de comment on définit un OS: si c'est juste le noyau ou le noyau + d'autres choses.
Je ne vois pas pourquoi l'OS serait lié à un langage particulier. C'est idiot. Y'a une libpas, aussi, une libada etc? C'est n'importe quoi.
-- -ed- [remove YOURBRA before answering me] The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html <blank line> FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Gabriel Dos Reis
Marc Boyer writes:
| Gabriel Dos Reis wrote: | > Marc Boyer writes: | >| Gabriel Dos Reis wrote: | >| > Marc Boyer writes: | >| Heuh... Je ne remets absolument pas en doute ta compétence, | >| mais j'aimerais alors avoir des explications. | >| Sur Linux, malloc/free sont dans libc, et pas dans GCC. | > | > 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.
[...]
| > La confusion vient de ce que certains donnent le même nom à deux | > choses qui sont conceptuellement différentes. | > | > L'OS fournit des primitives d'allocation dynamique (genre sbrk). | > Et l'implémentation peut utiliser ces primitives pour offrir malloc. | > Il arrive simplement que certains OS offrent des routines | > d'allocations qu'ils appellent malloc et que certains implémentations | > confusantes (et il en existe beaucoup) la repassent aux programmes. | | 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 ?
| 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 ? :-)
[...]
| "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 :-)
Merci.
-- Gaby
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> writes:
| Gabriel Dos Reis wrote:
| > Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> writes:
| >| Gabriel Dos Reis wrote:
| >| > Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> writes:
| >| Heuh... Je ne remets absolument pas en doute ta compétence,
| >| mais j'aimerais alors avoir des explications.
| >| Sur Linux, malloc/free sont dans libc, et pas dans GCC.
| >
| > 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.
[...]
| > La confusion vient de ce que certains donnent le même nom à deux
| > choses qui sont conceptuellement différentes.
| >
| > L'OS fournit des primitives d'allocation dynamique (genre sbrk).
| > Et l'implémentation peut utiliser ces primitives pour offrir malloc.
| > Il arrive simplement que certains OS offrent des routines
| > d'allocations qu'ils appellent malloc et que certains implémentations
| > confusantes (et il en existe beaucoup) la repassent aux programmes.
|
| 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 ?
| 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 ? :-)
[...]
| "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 :-)
| Gabriel Dos Reis wrote: | > Marc Boyer writes: | >| Gabriel Dos Reis wrote: | >| > Marc Boyer writes: | >| Heuh... Je ne remets absolument pas en doute ta compétence, | >| mais j'aimerais alors avoir des explications. | >| Sur Linux, malloc/free sont dans libc, et pas dans GCC. | > | > 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.
[...]
| > La confusion vient de ce que certains donnent le même nom à deux | > choses qui sont conceptuellement différentes. | > | > L'OS fournit des primitives d'allocation dynamique (genre sbrk). | > Et l'implémentation peut utiliser ces primitives pour offrir malloc. | > Il arrive simplement que certains OS offrent des routines | > d'allocations qu'ils appellent malloc et que certains implémentations | > confusantes (et il en existe beaucoup) la repassent aux programmes. | | 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 ?
| 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 ? :-)
[...]
| "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 :-)
