Chercher un livre sur le C avec certains critères.
200 réponses
Francois
Bonjour à tous,
Je débute dans le C et personnellement j'apprends surtout avec les
livres. J'ai commencé "Livre du C premier langage" de Delannoy (je
précise que j'avais quand même des petites notions de programmations,
même si, à mon sens, j'étais [ et suis encore ? ] vraiment ce qu'on
appelle un débutant).
Je suis en train de lire le K&R (deuxième édition) qui est bien sûr
beaucoup plus difficile. C'est du concentré, mais quand on y regarde de
prêt, c'est quand assez précis et bien fait. Ceci étant, il y a des
choses qui ne me satisfont pas complètement.
Je trouve que ce livre à une approche trop éloignée de la machine
(comment une donnée est encodée ? comment se passe l'histoire du signed
ou unsigned du point de vue de la machine etc.). Je m'explique.
Bien sûr, le langage C est un langage abstrait de "haut niveau" qui se
doit (en principe) de ne pas faire référence à la machine. Donc c'est
normal qu'un livre sur le C ne parle pas (trop) des problèmes qui
dépendent de l'architecture. Ceci étant, j'aimerais savoir si un tel
livre existe malgré tout. Un livre qui expose le langage C et qui
n'hésite pas de temps en temps à parler de ce qui se passe dans la
machine (bien sûr, justement, ce qui se passe dépend de la machine et
n'est pas universel, mais le livre pourrait présenter les choses sur
seulement une architecture "classique" par exemple). Bon, si je pouvais
éviter les circuits électroniques et compagnie quand même, ça serait
bien. Qu'on me dise que "le complément à 2 fait que l'addition devient
plus simple pour l'ordinateur puisqu'il suffit de faire une addition
classique" me suffit amplement. Une preuve de cela en passant des
explications sur des circuits électroniques peut-être me serait un peu
indigeste.
Bref, j'espère avoir été clair sur cette sorte de compromis que je
recherche (existe-t-il ?). Vous pouvez aller voir cette discussion (où
mon pseudo est sisco)
Je comprends l'idée. C'est vrai, mais je plaide non coupable, je suis un matheux. En maths, quand on présente un chapitre particulier, ce qui est présenté l'est en principe de manière "complète".
Oui, mais les maths, c'est virtuel, sans souci de compatibilité ascendante avec une machine populaire ayant fait un choix discutable il y a 30 ans de cela...
Je m'explique. Quand on apprend un cours sur les espaces vectoriels par exemple, on part de définitions à partir desquelles tout est construit au fur et à mesure. Donc en principe, à un instant donné, tout ce qui a été vu ne souffre d'aucune ambiguïté, d'aucune zone d'ombre, et se présente comme quelque d'achevé complètement (et je trouve ça très agréable, c'est pour ça que j'aime bien les maths). Après, on peut toujours continuer à aller plus loin dans telle ou telle théorie (et s'apercevoir que finalement on n'en verra jamais le bout bien sûr), mais ce qui est "derrière soi" à un côté achevé, ça c'est cool.
J'ai sûrement tendance à vouloir reproduire ce schéma dans d'autre activité, ce qui est bien sûr une chimère. Bon en fait, même en maths c'est quand même une chimère, mais vachement moins que dans d'autres activités (mais là je m'égare).
Tu occultes aussi le fait que quand on apprend à compter, on ne le fait pas en présentant la théorie. De même, on commence pas la géométrie par la vingtaine d'axiomes de la théorie Euclidienne.
Sans parler du fait que certains matheux ne font jamais de logique, et ne savent même pas quels sont les fondements de leurs raisonnements ;-)
Donc, premièe question: tu savais déjà programmer avant de t'intéresser au C ? Tu avais déjà des notions d'archi des ordis ? Non ? Ben alors, tu es dans la situation de quelqu'un n'ayant jamais fait de calcul, de géométrie, et à qui on présenterait les espaces Euclidiens...
J'espère avoir été clair ? Bon, et puis désolé si j'ai un peu fait le p'tit péteux qui débarque la fleur au fusil. Je pense qu'il faut que jeunesse se passe. :-))
Mais, ce forum est aussi là pour ça.
J'ai eu plein de réponses et la discussion m'a fichtrement intéressée et amusée. C'est vrai, pourquoi diable un domaine comme l'informatique déchaîne-t-il toujours les passions ? (ce n'est pas péjoratif dans ma bouche)
Tu connais des dommaines techniques qui ne déclenchent pas des passions entre professionels ? L'histoire et la psycho sont tellement déchaînées que même la presse s'en fait l'écho.
Bref, je vais continuer à lire le K&R (j'ai déjà des questions dans ma besace ... c'est pour bientôt sur le fclc :-) ). Et puis après on verra... c'est pour bientôt sur le fclc :-) ). Et puis après on verra...
Le chapitre 6 du Harbison&Steele est aussi une bonne chose.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
On 2008-03-10, Francois <mathsattacks@free.fr> wrote:
Et toi, tu voudrais un bouquin avec tout ?
Je comprends l'idée. C'est vrai, mais je plaide non coupable, je suis un
matheux. En maths, quand on présente un chapitre particulier, ce qui est
présenté l'est en principe de manière "complète".
Oui, mais les maths, c'est virtuel, sans souci de compatibilité
ascendante avec une machine populaire ayant fait un choix discutable
il y a 30 ans de cela...
Je m'explique. Quand on apprend un cours sur les espaces vectoriels par
exemple, on part de définitions à partir desquelles tout est construit
au fur et à mesure. Donc en principe, à un instant donné, tout ce qui a
été vu ne souffre d'aucune ambiguïté, d'aucune zone d'ombre, et se
présente comme quelque d'achevé complètement (et je trouve ça très
agréable, c'est pour ça que j'aime bien les maths). Après, on peut
toujours continuer à aller plus loin dans telle ou telle théorie (et
s'apercevoir que finalement on n'en verra jamais le bout bien sûr), mais
ce qui est "derrière soi" à un côté achevé, ça c'est cool.
J'ai sûrement tendance à vouloir reproduire ce schéma dans d'autre
activité, ce qui est bien sûr une chimère. Bon en fait, même en maths
c'est quand même une chimère, mais vachement moins que dans d'autres
activités (mais là je m'égare).
Tu occultes aussi le fait que quand on apprend à compter, on ne le
fait pas en présentant la théorie.
De même, on commence pas la géométrie par la vingtaine d'axiomes
de la théorie Euclidienne.
Sans parler du fait que certains matheux ne font jamais de logique,
et ne savent même pas quels sont les fondements de leurs raisonnements
;-)
Donc, premièe question: tu savais déjà programmer avant de
t'intéresser au C ? Tu avais déjà des notions d'archi des ordis ?
Non ? Ben alors, tu es dans la situation de quelqu'un n'ayant
jamais fait de calcul, de géométrie, et à qui on présenterait
les espaces Euclidiens...
J'espère avoir été clair ?
Bon, et puis désolé si j'ai un peu fait le p'tit péteux qui débarque la
fleur au fusil. Je pense qu'il faut que jeunesse se passe. :-))
Mais, ce forum est aussi là pour ça.
J'ai eu plein de réponses et la discussion m'a fichtrement intéressée et
amusée. C'est vrai, pourquoi diable un domaine comme l'informatique
déchaîne-t-il toujours les passions ? (ce n'est pas péjoratif dans ma
bouche)
Tu connais des dommaines techniques qui ne déclenchent pas des
passions entre professionels ? L'histoire et la psycho sont tellement
déchaînées que même la presse s'en fait l'écho.
Bref, je vais continuer à lire le K&R (j'ai déjà des questions dans ma
besace ... c'est pour bientôt sur le fclc :-) ). Et puis après on
verra... c'est pour bientôt sur le fclc :-) ). Et puis après on verra...
Le chapitre 6 du Harbison&Steele est aussi une bonne chose.
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Je comprends l'idée. C'est vrai, mais je plaide non coupable, je suis un matheux. En maths, quand on présente un chapitre particulier, ce qui est présenté l'est en principe de manière "complète".
Oui, mais les maths, c'est virtuel, sans souci de compatibilité ascendante avec une machine populaire ayant fait un choix discutable il y a 30 ans de cela...
Je m'explique. Quand on apprend un cours sur les espaces vectoriels par exemple, on part de définitions à partir desquelles tout est construit au fur et à mesure. Donc en principe, à un instant donné, tout ce qui a été vu ne souffre d'aucune ambiguïté, d'aucune zone d'ombre, et se présente comme quelque d'achevé complètement (et je trouve ça très agréable, c'est pour ça que j'aime bien les maths). Après, on peut toujours continuer à aller plus loin dans telle ou telle théorie (et s'apercevoir que finalement on n'en verra jamais le bout bien sûr), mais ce qui est "derrière soi" à un côté achevé, ça c'est cool.
J'ai sûrement tendance à vouloir reproduire ce schéma dans d'autre activité, ce qui est bien sûr une chimère. Bon en fait, même en maths c'est quand même une chimère, mais vachement moins que dans d'autres activités (mais là je m'égare).
Tu occultes aussi le fait que quand on apprend à compter, on ne le fait pas en présentant la théorie. De même, on commence pas la géométrie par la vingtaine d'axiomes de la théorie Euclidienne.
Sans parler du fait que certains matheux ne font jamais de logique, et ne savent même pas quels sont les fondements de leurs raisonnements ;-)
Donc, premièe question: tu savais déjà programmer avant de t'intéresser au C ? Tu avais déjà des notions d'archi des ordis ? Non ? Ben alors, tu es dans la situation de quelqu'un n'ayant jamais fait de calcul, de géométrie, et à qui on présenterait les espaces Euclidiens...
J'espère avoir été clair ? Bon, et puis désolé si j'ai un peu fait le p'tit péteux qui débarque la fleur au fusil. Je pense qu'il faut que jeunesse se passe. :-))
Mais, ce forum est aussi là pour ça.
J'ai eu plein de réponses et la discussion m'a fichtrement intéressée et amusée. C'est vrai, pourquoi diable un domaine comme l'informatique déchaîne-t-il toujours les passions ? (ce n'est pas péjoratif dans ma bouche)
Tu connais des dommaines techniques qui ne déclenchent pas des passions entre professionels ? L'histoire et la psycho sont tellement déchaînées que même la presse s'en fait l'écho.
Bref, je vais continuer à lire le K&R (j'ai déjà des questions dans ma besace ... c'est pour bientôt sur le fclc :-) ). Et puis après on verra... c'est pour bientôt sur le fclc :-) ). Et puis après on verra...
Le chapitre 6 du Harbison&Steele est aussi une bonne chose.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Jean-Marc Bourguet
Marc Boyer writes:
Ou alors, ca me parait plus important d'evoquer les regles d'aliasing de type, qui sont elles *vraiment* tordues.
Peux-tu me rappeller ce que tu appelles "aliasing" ?
Les regles qui disent que le compilateur peut supposer que modifier un membre int d'une structure A ne modifie pas un membre int d'une structure B sauf si une declaration d'une union contenant un membre de type struct A et un autre de type struct B est visible et que les struct commencent par des membres du meme type jusqu'aux membres consideres. (Je suis pas clair mais c'est pas grave).
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
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Ou alors, ca me parait plus important d'evoquer les regles d'aliasing
de type, qui sont elles *vraiment* tordues.
Peux-tu me rappeller ce que tu appelles "aliasing" ?
Les regles qui disent que le compilateur peut supposer que modifier un
membre int d'une structure A ne modifie pas un membre int d'une structure B
sauf si une declaration d'une union contenant un membre de type struct A et
un autre de type struct B est visible et que les struct commencent par des
membres du meme type jusqu'aux membres consideres. (Je suis pas clair mais
c'est pas grave).
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
Ou alors, ca me parait plus important d'evoquer les regles d'aliasing de type, qui sont elles *vraiment* tordues.
Peux-tu me rappeller ce que tu appelles "aliasing" ?
Les regles qui disent que le compilateur peut supposer que modifier un membre int d'une structure A ne modifie pas un membre int d'une structure B sauf si une declaration d'une union contenant un membre de type struct A et un autre de type struct B est visible et que les struct commencent par des membres du meme type jusqu'aux membres consideres. (Je suis pas clair mais c'est pas grave).
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
espie
In article , Marc Boyer wrote:
On 2008-03-10, Marc Espie wrote:
In article <fr481f$ju8$, Marc Boyer wrote:
Si on part de l'idée naïve qu'un pointeur est un entier représentant l'adresse d'un char (représentation courante), alors, toutes les subtilités de conversions entre pointeurs semblent là juste pour compliquer les choses.
Euh, ces temps-ci, les regles a la con, c'est plus des problemes d'alignement sur les trucs plus gros, ou des octets de bourrage... ou alors, les vrais problemes de difference signe/pas signe... D'ailleurs ptrdiff_t et size_t ne font qu'ajouter a l'immonde bordel ambient.
C'est vrai que j'avais zappé les alignements tellement ça me paraît "naturel" maintenant ;-) Je pensais à des trucs comme le "one past end".
Ca, c'est une realite. De plus en plus, meme. Une des facons de lutter contre les buffer-overflow, c'est de jouer avec la carte memoire de ton systeme. Typiquement, en essayant de placer certains malloc a la frontiere d'une page, et en s'arrangeant pour que la page suivante (ou precedente) declenche une segmentation fault.
C'est deprimant le nombre de programmes mal ecrits qu'on arrive a detecter avec ca, d'ailleurs... qui jouent avec des pointeurs deux ou trois octets apres/avant ce a quoi ils ont droit.
In article <slrnftch7o.610.Marc.Boyer@ubu.enseeiht.fr>,
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:
On 2008-03-10, Marc Espie <espie@lain.home> wrote:
In article <fr481f$ju8$1@news.cict.fr>,
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:
Si on part de l'idée naïve qu'un pointeur est un entier représentant
l'adresse d'un char (représentation courante), alors, toutes les
subtilités de conversions entre pointeurs semblent là juste pour
compliquer les choses.
Euh, ces temps-ci, les regles a la con, c'est plus des problemes d'alignement
sur les trucs plus gros, ou des octets de bourrage... ou alors, les
vrais problemes de difference signe/pas signe... D'ailleurs ptrdiff_t et
size_t ne font qu'ajouter a l'immonde bordel ambient.
C'est vrai que j'avais zappé les alignements tellement ça me
paraît "naturel" maintenant ;-) Je pensais à des trucs comme
le "one past end".
Ca, c'est une realite. De plus en plus, meme. Une des facons de lutter
contre les buffer-overflow, c'est de jouer avec la carte memoire de ton
systeme. Typiquement, en essayant de placer certains malloc a la
frontiere d'une page, et en s'arrangeant pour que la page suivante (ou
precedente) declenche une segmentation fault.
C'est deprimant le nombre de programmes mal ecrits qu'on arrive a detecter
avec ca, d'ailleurs... qui jouent avec des pointeurs deux ou trois octets
apres/avant ce a quoi ils ont droit.
Si on part de l'idée naïve qu'un pointeur est un entier représentant l'adresse d'un char (représentation courante), alors, toutes les subtilités de conversions entre pointeurs semblent là juste pour compliquer les choses.
Euh, ces temps-ci, les regles a la con, c'est plus des problemes d'alignement sur les trucs plus gros, ou des octets de bourrage... ou alors, les vrais problemes de difference signe/pas signe... D'ailleurs ptrdiff_t et size_t ne font qu'ajouter a l'immonde bordel ambient.
C'est vrai que j'avais zappé les alignements tellement ça me paraît "naturel" maintenant ;-) Je pensais à des trucs comme le "one past end".
Ca, c'est une realite. De plus en plus, meme. Une des facons de lutter contre les buffer-overflow, c'est de jouer avec la carte memoire de ton systeme. Typiquement, en essayant de placer certains malloc a la frontiere d'une page, et en s'arrangeant pour que la page suivante (ou precedente) declenche une segmentation fault.
C'est deprimant le nombre de programmes mal ecrits qu'on arrive a detecter avec ca, d'ailleurs... qui jouent avec des pointeurs deux ou trois octets apres/avant ce a quoi ils ont droit.
espie
In article , Marc Boyer wrote:
Tient, ce matin en TD "mais monsieur, pourquoi il faut mettre 'static' devant les fonctions qui sont dans le .c et pas dans le .h ? Le compilo peut pas s'en appercevoir tout seul ?" Ben si, il pourrait facile en 2008. Mais en 1974, c'était différent...
Non, toujours pas en 2008... Comment tu fais la difference entre les fonctions qui ne sont pas dans le .h de facon intentionnelle, et celles qui n'y sont pas parce qu'on les a oubliees ?
Je n'en fais pas. D'ailleurs, celles qu'on a oublié, si on les utilise ailleurs, ce sera une utilisation sans prototype, et ça risque de pas bien marcher. Donc, ça ne va casser que du mauvais code.
Super...
je prefere l'approche un peu plus robuste, industrielle et verbeuse. D'ailleurs les -Wmissing-prototypes sont un peu une seconde nature chez moi.
In article <slrnftch7o.610.Marc.Boyer@ubu.enseeiht.fr>,
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:
Tient, ce matin en TD "mais monsieur, pourquoi il faut mettre
'static' devant les fonctions qui sont dans le .c et pas dans le
.h ? Le compilo peut pas s'en appercevoir tout seul ?"
Ben si, il pourrait facile en 2008. Mais en 1974, c'était différent...
Non, toujours pas en 2008... Comment tu fais la difference entre les
fonctions qui ne sont pas dans le .h de facon intentionnelle, et celles
qui n'y sont pas parce qu'on les a oubliees ?
Je n'en fais pas. D'ailleurs, celles qu'on a oublié, si on les utilise
ailleurs, ce sera une utilisation sans prototype, et ça risque de pas
bien marcher.
Donc, ça ne va casser que du mauvais code.
Super...
je prefere l'approche un peu plus robuste, industrielle et verbeuse.
D'ailleurs les -Wmissing-prototypes sont un peu une seconde nature chez moi.
Tient, ce matin en TD "mais monsieur, pourquoi il faut mettre 'static' devant les fonctions qui sont dans le .c et pas dans le .h ? Le compilo peut pas s'en appercevoir tout seul ?" Ben si, il pourrait facile en 2008. Mais en 1974, c'était différent...
Non, toujours pas en 2008... Comment tu fais la difference entre les fonctions qui ne sont pas dans le .h de facon intentionnelle, et celles qui n'y sont pas parce qu'on les a oubliees ?
Je n'en fais pas. D'ailleurs, celles qu'on a oublié, si on les utilise ailleurs, ce sera une utilisation sans prototype, et ça risque de pas bien marcher. Donc, ça ne va casser que du mauvais code.
Super...
je prefere l'approche un peu plus robuste, industrielle et verbeuse. D'ailleurs les -Wmissing-prototypes sont un peu une seconde nature chez moi.
espie
In article , Marc Boyer wrote:
Ou alors, ca me parait plus important d'evoquer les regles d'aliasing de type, qui sont elles *vraiment* tordues.
Peux-tu me rappeller ce que tu appelles "aliasing" ?
En Fortran, il y a un vrai type tableau. Ca permet aux physicien de faire la nique au gens du C avec des optimisations `impossibles' en C, parce qu'on ne sait pas trop si deux pointeurs correspondent a la meme zone memoire ou pas (aliasing).
Les normes recentes (je sais plus si c'est deja en C89) introduisent un typage fort: deux pointeurs de types differents ne peuvent pas correspondre a la meme zone memoire, et donc le compilo a le droit de faire des optimisations assez tordues.
Typiquement, ca pose des problemes au code qui suppose trop de chose sur la representation memoire des objets, donc a pas mal de mauvais code... et a un peu de code tres bas niveau, de style compilateur lisp ou assimile, qui fait souvent des choses bizarres avec ces donnees.
Si tu veux du mal a quelqu'un, maudis-le a corriger des bugs d'aliasing... c'est un peu comme les volatile manquants, mais en pire. ;-)
(comme on est en C, quand meme, la notion de type different est assez tordue, puisqu'on regarde dans le pointeur pour savoir a quoi on a vraiment affaire comme donnee... ainsi un struct { int a } *p et un int *q ont parfaitement le droit de pointer sur la meme zone memoire, le systeme unifie egalement signed/unsigned, et considere que tout acces a travers un (signed/unsigned/) char * ou un void * peut etre aliase par n'importe quoi.)
Il y a egalement un 2e mecanisme, __restrict, mais celui-ci est encore plus foireux pour le compilateur (confere de looongues discussions sur la ml gcc sur ce que __restrict signifie), et ne se rencontre guere que dans les protos de fonctions standards, la ou la norme le reclame (et permet, avec son ami const, de finir de casser du code foireux qui redeclare tout seul comme un grand des fonctions de la bibliotheque standard).
In article <slrnftch7o.610.Marc.Boyer@ubu.enseeiht.fr>,
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:
Ou alors, ca me parait plus important d'evoquer les regles d'aliasing
de type, qui sont elles *vraiment* tordues.
Peux-tu me rappeller ce que tu appelles "aliasing" ?
En Fortran, il y a un vrai type tableau. Ca permet aux physicien de faire
la nique au gens du C avec des optimisations `impossibles' en C, parce
qu'on ne sait pas trop si deux pointeurs correspondent a la meme zone
memoire ou pas (aliasing).
Les normes recentes (je sais plus si c'est deja en C89) introduisent un
typage fort: deux pointeurs de types differents ne peuvent pas correspondre
a la meme zone memoire, et donc le compilo a le droit de faire des
optimisations assez tordues.
Typiquement, ca pose des problemes au code qui suppose trop de chose sur
la representation memoire des objets, donc a pas mal de mauvais code...
et a un peu de code tres bas niveau, de style compilateur lisp ou assimile,
qui fait souvent des choses bizarres avec ces donnees.
Si tu veux du mal a quelqu'un, maudis-le a corriger des bugs d'aliasing...
c'est un peu comme les volatile manquants, mais en pire.
;-)
(comme on est en C, quand meme, la notion de type different est assez tordue,
puisqu'on regarde dans le pointeur pour savoir a quoi on a vraiment affaire
comme donnee... ainsi un struct { int a } *p et un int *q ont parfaitement
le droit de pointer sur la meme zone memoire, le systeme unifie egalement
signed/unsigned, et considere que tout acces a travers un
(signed/unsigned/) char * ou un void * peut etre aliase par n'importe
quoi.)
Il y a egalement un 2e mecanisme, __restrict, mais celui-ci est encore plus
foireux pour le compilateur (confere de looongues discussions sur la ml
gcc sur ce que __restrict signifie), et ne se rencontre guere que dans
les protos de fonctions standards, la ou la norme le reclame (et permet,
avec son ami const, de finir de casser du code foireux qui redeclare tout
seul comme un grand des fonctions de la bibliotheque standard).
Ou alors, ca me parait plus important d'evoquer les regles d'aliasing de type, qui sont elles *vraiment* tordues.
Peux-tu me rappeller ce que tu appelles "aliasing" ?
En Fortran, il y a un vrai type tableau. Ca permet aux physicien de faire la nique au gens du C avec des optimisations `impossibles' en C, parce qu'on ne sait pas trop si deux pointeurs correspondent a la meme zone memoire ou pas (aliasing).
Les normes recentes (je sais plus si c'est deja en C89) introduisent un typage fort: deux pointeurs de types differents ne peuvent pas correspondre a la meme zone memoire, et donc le compilo a le droit de faire des optimisations assez tordues.
Typiquement, ca pose des problemes au code qui suppose trop de chose sur la representation memoire des objets, donc a pas mal de mauvais code... et a un peu de code tres bas niveau, de style compilateur lisp ou assimile, qui fait souvent des choses bizarres avec ces donnees.
Si tu veux du mal a quelqu'un, maudis-le a corriger des bugs d'aliasing... c'est un peu comme les volatile manquants, mais en pire. ;-)
(comme on est en C, quand meme, la notion de type different est assez tordue, puisqu'on regarde dans le pointeur pour savoir a quoi on a vraiment affaire comme donnee... ainsi un struct { int a } *p et un int *q ont parfaitement le droit de pointer sur la meme zone memoire, le systeme unifie egalement signed/unsigned, et considere que tout acces a travers un (signed/unsigned/) char * ou un void * peut etre aliase par n'importe quoi.)
Il y a egalement un 2e mecanisme, __restrict, mais celui-ci est encore plus foireux pour le compilateur (confere de looongues discussions sur la ml gcc sur ce que __restrict signifie), et ne se rencontre guere que dans les protos de fonctions standards, la ou la norme le reclame (et permet, avec son ami const, de finir de casser du code foireux qui redeclare tout seul comme un grand des fonctions de la bibliotheque standard).
Jean-Marc Bourguet
(Marc Espie) writes:
In article , Marc Boyer wrote:
Ou alors, ca me parait plus important d'evoquer les regles d'aliasing de type, qui sont elles *vraiment* tordues.
Peux-tu me rappeller ce que tu appelles "aliasing" ?
En Fortran, il y a un vrai type tableau. Ca permet aux physicien de faire la nique au gens du C avec des optimisations `impossibles' en C, parce qu'on ne sait pas trop si deux pointeurs correspondent a la meme zone memoire ou pas (aliasing).
Les normes recentes (je sais plus si c'est deja en C89) introduisent un De memoire, oui.
typage fort: deux pointeurs de types differents ne peuvent pas correspondre a la meme zone memoire, et donc le compilo a le droit de faire des optimisations assez tordues. [...]
(comme on est en C, quand meme, la notion de type different est assez tordue, puisqu'on regarde dans le pointeur pour savoir a quoi on a vraiment affaire comme donnee... ainsi un struct { int a } *p et un int *q ont parfaitement le droit de pointer sur la meme zone memoire, le systeme unifie egalement signed/unsigned,
Tu es sur sur ou n'est-ce que la technique utilisees par les compilateurs pour eviter de tout casser (ca ne correspond pas a ce que j'avais cru comprendre)
et considere que tout acces a travers un (signed/unsigned/) char * ou un void * peut etre aliase par n'importe quoi.)
Ca correspond a ma memoire mais les acces a travers void* sont rares :-)
(Il y a la regle introduite pour valider l'OO a la Xlib qui n'est pas mal non plus dans le genre).
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
espie@lain.home (Marc Espie) writes:
In article <slrnftch7o.610.Marc.Boyer@ubu.enseeiht.fr>,
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:
Ou alors, ca me parait plus important d'evoquer les regles d'aliasing
de type, qui sont elles *vraiment* tordues.
Peux-tu me rappeller ce que tu appelles "aliasing" ?
En Fortran, il y a un vrai type tableau. Ca permet aux physicien de faire
la nique au gens du C avec des optimisations `impossibles' en C, parce
qu'on ne sait pas trop si deux pointeurs correspondent a la meme zone
memoire ou pas (aliasing).
Les normes recentes (je sais plus si c'est deja en C89) introduisent un
De memoire, oui.
typage fort: deux pointeurs de types differents ne peuvent pas correspondre
a la meme zone memoire, et donc le compilo a le droit de faire des
optimisations assez tordues.
[...]
(comme on est en C, quand meme, la notion de type different est assez tordue,
puisqu'on regarde dans le pointeur pour savoir a quoi on a vraiment affaire
comme donnee... ainsi un struct { int a } *p et un int *q ont parfaitement
le droit de pointer sur la meme zone memoire, le systeme unifie egalement
signed/unsigned,
Tu es sur sur ou n'est-ce que la technique utilisees par les compilateurs
pour eviter de tout casser (ca ne correspond pas a ce que j'avais cru comprendre)
et considere que tout acces a travers un (signed/unsigned/) char * ou un
void * peut etre aliase par n'importe quoi.)
Ca correspond a ma memoire mais les acces a travers void* sont rares :-)
(Il y a la regle introduite pour valider l'OO a la Xlib qui n'est pas mal
non plus dans le genre).
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
Ou alors, ca me parait plus important d'evoquer les regles d'aliasing de type, qui sont elles *vraiment* tordues.
Peux-tu me rappeller ce que tu appelles "aliasing" ?
En Fortran, il y a un vrai type tableau. Ca permet aux physicien de faire la nique au gens du C avec des optimisations `impossibles' en C, parce qu'on ne sait pas trop si deux pointeurs correspondent a la meme zone memoire ou pas (aliasing).
Les normes recentes (je sais plus si c'est deja en C89) introduisent un De memoire, oui.
typage fort: deux pointeurs de types differents ne peuvent pas correspondre a la meme zone memoire, et donc le compilo a le droit de faire des optimisations assez tordues. [...]
(comme on est en C, quand meme, la notion de type different est assez tordue, puisqu'on regarde dans le pointeur pour savoir a quoi on a vraiment affaire comme donnee... ainsi un struct { int a } *p et un int *q ont parfaitement le droit de pointer sur la meme zone memoire, le systeme unifie egalement signed/unsigned,
Tu es sur sur ou n'est-ce que la technique utilisees par les compilateurs pour eviter de tout casser (ca ne correspond pas a ce que j'avais cru comprendre)
et considere que tout acces a travers un (signed/unsigned/) char * ou un void * peut etre aliase par n'importe quoi.)
Ca correspond a ma memoire mais les acces a travers void* sont rares :-)
(Il y a la regle introduite pour valider l'OO a la Xlib qui n'est pas mal non plus dans le genre).
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
Marc Boyer
On 2008-03-11, Marc Espie wrote:
In article , Marc Boyer wrote:
Tient, ce matin en TD "mais monsieur, pourquoi il faut mettre 'static' devant les fonctions qui sont dans le .c et pas dans le .h ? Le compilo peut pas s'en appercevoir tout seul ?" Ben si, il pourrait facile en 2008. Mais en 1974, c'était différent...
Non, toujours pas en 2008... Comment tu fais la difference entre les fonctions qui ne sont pas dans le .h de facon intentionnelle, et celles qui n'y sont pas parce qu'on les a oubliees ?
Je n'en fais pas. D'ailleurs, celles qu'on a oublié, si on les utilise ailleurs, ce sera une utilisation sans prototype, et ça risque de pas bien marcher. Donc, ça ne va casser que du mauvais code.
Super...
je prefere l'approche un peu plus robuste, industrielle et verbeuse.
Que cela va-t-il changer ? D'ailleurs, si tu oublies de mettre le static, tu peux avoir collision avec une fonction de même nom déclarée elle tout à fait correctement dans un .h.
D'ailleurs les -Wmissing-prototypes sont un peu une seconde nature chez moi.
Et ce warning va bien dans le sens que toutes les fonctions sans prototype (donc pas dans le ?h) devraient être statiques.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
On 2008-03-11, Marc Espie <espie@lain.home> wrote:
In article <slrnftch7o.610.Marc.Boyer@ubu.enseeiht.fr>,
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:
Tient, ce matin en TD "mais monsieur, pourquoi il faut mettre
'static' devant les fonctions qui sont dans le .c et pas dans le
.h ? Le compilo peut pas s'en appercevoir tout seul ?"
Ben si, il pourrait facile en 2008. Mais en 1974, c'était différent...
Non, toujours pas en 2008... Comment tu fais la difference entre les
fonctions qui ne sont pas dans le .h de facon intentionnelle, et celles
qui n'y sont pas parce qu'on les a oubliees ?
Je n'en fais pas. D'ailleurs, celles qu'on a oublié, si on les utilise
ailleurs, ce sera une utilisation sans prototype, et ça risque de pas
bien marcher.
Donc, ça ne va casser que du mauvais code.
Super...
je prefere l'approche un peu plus robuste, industrielle et verbeuse.
Que cela va-t-il changer ?
D'ailleurs, si tu oublies de mettre le static, tu peux avoir
collision avec une fonction de même nom déclarée elle tout à fait
correctement dans un .h.
D'ailleurs les -Wmissing-prototypes sont un peu une seconde nature chez moi.
Et ce warning va bien dans le sens que toutes les fonctions
sans prototype (donc pas dans le ?h) devraient être statiques.
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Tient, ce matin en TD "mais monsieur, pourquoi il faut mettre 'static' devant les fonctions qui sont dans le .c et pas dans le .h ? Le compilo peut pas s'en appercevoir tout seul ?" Ben si, il pourrait facile en 2008. Mais en 1974, c'était différent...
Non, toujours pas en 2008... Comment tu fais la difference entre les fonctions qui ne sont pas dans le .h de facon intentionnelle, et celles qui n'y sont pas parce qu'on les a oubliees ?
Je n'en fais pas. D'ailleurs, celles qu'on a oublié, si on les utilise ailleurs, ce sera une utilisation sans prototype, et ça risque de pas bien marcher. Donc, ça ne va casser que du mauvais code.
Super...
je prefere l'approche un peu plus robuste, industrielle et verbeuse.
Que cela va-t-il changer ? D'ailleurs, si tu oublies de mettre le static, tu peux avoir collision avec une fonction de même nom déclarée elle tout à fait correctement dans un .h.
D'ailleurs les -Wmissing-prototypes sont un peu une seconde nature chez moi.
Et ce warning va bien dans le sens que toutes les fonctions sans prototype (donc pas dans le ?h) devraient être statiques.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Marc Boyer
On 2008-03-11, Jean-Marc Bourguet wrote:
Marc Boyer writes:
Ou alors, ca me parait plus important d'evoquer les regles d'aliasing de type, qui sont elles *vraiment* tordues.
Peux-tu me rappeller ce que tu appelles "aliasing" ?
Les regles qui disent que le compilateur peut supposer que modifier un membre int d'une structure A ne modifie pas un membre int d'une structure B sauf si une declaration d'une union contenant un membre de type struct A et un autre de type struct B est visible et que les struct commencent par des membres du meme type jusqu'aux membres consideres. (Je suis pas clair mais c'est pas grave).
Si, si, je vois bien. C'est 6.5.3.3/5 et exemple 3.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
On 2008-03-11, Jean-Marc Bourguet <jm@bourguet.org> wrote:
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr.invalid> writes:
Ou alors, ca me parait plus important d'evoquer les regles d'aliasing
de type, qui sont elles *vraiment* tordues.
Peux-tu me rappeller ce que tu appelles "aliasing" ?
Les regles qui disent que le compilateur peut supposer que modifier un
membre int d'une structure A ne modifie pas un membre int d'une structure B
sauf si une declaration d'une union contenant un membre de type struct A et
un autre de type struct B est visible et que les struct commencent par des
membres du meme type jusqu'aux membres consideres. (Je suis pas clair mais
c'est pas grave).
Si, si, je vois bien.
C'est 6.5.3.3/5 et exemple 3.
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Ou alors, ca me parait plus important d'evoquer les regles d'aliasing de type, qui sont elles *vraiment* tordues.
Peux-tu me rappeller ce que tu appelles "aliasing" ?
Les regles qui disent que le compilateur peut supposer que modifier un membre int d'une structure A ne modifie pas un membre int d'une structure B sauf si une declaration d'une union contenant un membre de type struct A et un autre de type struct B est visible et que les struct commencent par des membres du meme type jusqu'aux membres consideres. (Je suis pas clair mais c'est pas grave).
Si, si, je vois bien. C'est 6.5.3.3/5 et exemple 3.
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
Marc Boyer
On 2008-03-11, Marc Espie wrote:
In article , Marc Boyer wrote:
On 2008-03-10, Marc Espie wrote:
In article <fr481f$ju8$, Marc Boyer wrote:
Si on part de l'idée naïve qu'un pointeur est un entier représentant l'adresse d'un char (représentation courante), alors, toutes les subtilités de conversions entre pointeurs semblent là juste pour compliquer les choses.
Euh, ces temps-ci, les regles a la con, c'est plus des problemes d'alignement sur les trucs plus gros, ou des octets de bourrage... ou alors, les vrais problemes de difference signe/pas signe... D'ailleurs ptrdiff_t et size_t ne font qu'ajouter a l'immonde bordel ambient.
C'est vrai que j'avais zappé les alignements tellement ça me paraît "naturel" maintenant ;-) Je pensais à des trucs comme le "one past end".
Ca, c'est une realite. De plus en plus, meme. Une des facons de lutter contre les buffer-overflow, c'est de jouer avec la carte memoire de ton systeme. Typiquement, en essayant de placer certains malloc a la frontiere d'une page, et en s'arrangeant pour que la page suivante (ou precedente) declenche une segmentation fault.
C'est deprimant le nombre de programmes mal ecrits qu'on arrive a detecter avec ca, d'ailleurs... qui jouent avec des pointeurs deux ou trois octets apres/avant ce a quoi ils ont droit.
Des trucs que l'on arrivait pas à détecter avec purify ou valgrind ?
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
On 2008-03-11, Marc Espie <espie@lain.home> wrote:
In article <slrnftch7o.610.Marc.Boyer@ubu.enseeiht.fr>,
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:
On 2008-03-10, Marc Espie <espie@lain.home> wrote:
In article <fr481f$ju8$1@news.cict.fr>,
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:
Si on part de l'idée naïve qu'un pointeur est un entier représentant
l'adresse d'un char (représentation courante), alors, toutes les
subtilités de conversions entre pointeurs semblent là juste pour
compliquer les choses.
Euh, ces temps-ci, les regles a la con, c'est plus des problemes d'alignement
sur les trucs plus gros, ou des octets de bourrage... ou alors, les
vrais problemes de difference signe/pas signe... D'ailleurs ptrdiff_t et
size_t ne font qu'ajouter a l'immonde bordel ambient.
C'est vrai que j'avais zappé les alignements tellement ça me
paraît "naturel" maintenant ;-) Je pensais à des trucs comme
le "one past end".
Ca, c'est une realite. De plus en plus, meme. Une des facons de lutter
contre les buffer-overflow, c'est de jouer avec la carte memoire de ton
systeme. Typiquement, en essayant de placer certains malloc a la
frontiere d'une page, et en s'arrangeant pour que la page suivante (ou
precedente) declenche une segmentation fault.
C'est deprimant le nombre de programmes mal ecrits qu'on arrive a detecter
avec ca, d'ailleurs... qui jouent avec des pointeurs deux ou trois octets
apres/avant ce a quoi ils ont droit.
Des trucs que l'on arrivait pas à détecter avec purify ou valgrind ?
Marc Boyer
--
Si tu peux supporter d'entendre tes paroles
Travesties par des gueux pour exciter des sots
IF -- Rudyard Kipling (Trad. André Maurois)
Si on part de l'idée naïve qu'un pointeur est un entier représentant l'adresse d'un char (représentation courante), alors, toutes les subtilités de conversions entre pointeurs semblent là juste pour compliquer les choses.
Euh, ces temps-ci, les regles a la con, c'est plus des problemes d'alignement sur les trucs plus gros, ou des octets de bourrage... ou alors, les vrais problemes de difference signe/pas signe... D'ailleurs ptrdiff_t et size_t ne font qu'ajouter a l'immonde bordel ambient.
C'est vrai que j'avais zappé les alignements tellement ça me paraît "naturel" maintenant ;-) Je pensais à des trucs comme le "one past end".
Ca, c'est une realite. De plus en plus, meme. Une des facons de lutter contre les buffer-overflow, c'est de jouer avec la carte memoire de ton systeme. Typiquement, en essayant de placer certains malloc a la frontiere d'une page, et en s'arrangeant pour que la page suivante (ou precedente) declenche une segmentation fault.
C'est deprimant le nombre de programmes mal ecrits qu'on arrive a detecter avec ca, d'ailleurs... qui jouent avec des pointeurs deux ou trois octets apres/avant ce a quoi ils ont droit.
Des trucs que l'on arrivait pas à détecter avec purify ou valgrind ?
Marc Boyer -- Si tu peux supporter d'entendre tes paroles Travesties par des gueux pour exciter des sots IF -- Rudyard Kipling (Trad. André Maurois)
espie
In article , Marc Boyer wrote:
Des trucs que l'on arrivait pas à détecter avec purify ou valgrind ?
Je soupconne que oui. En particulier, les acces une case avant le tableau. Typiquement, on a corrige un sacre paquet pour arriver a compiler openoffice sur OpenBSD: il y avait pas mal d'acces illegaux dans dmake...
In article <slrnftcqd1.610.Marc.Boyer@ubu.enseeiht.fr>,
Marc Boyer <Marc.Boyer@enseeiht.yahoo.fr> wrote:
Des trucs que l'on arrivait pas à détecter avec purify ou valgrind ?
Je soupconne que oui. En particulier, les acces une case avant le tableau.
Typiquement, on a corrige un sacre paquet pour arriver a compiler openoffice
sur OpenBSD: il y avait pas mal d'acces illegaux dans dmake...
Des trucs que l'on arrivait pas à détecter avec purify ou valgrind ?
Je soupconne que oui. En particulier, les acces une case avant le tableau. Typiquement, on a corrige un sacre paquet pour arriver a compiler openoffice sur OpenBSD: il y avait pas mal d'acces illegaux dans dmake...
