C'est surtout que j'ai pas compris en quoi ca permettait de faire du code plus performant...
// utils.c
void CalcDim(LINE *s) {
s->w=0; s->h=0;
s->p=s->p0; s->style=s->style0;
while (*s->p++) {
int x,y;
CalcChar(s,&x,&y,0);
s->w+=x; s->h=max(s->h,y);
}
}
// chars.c
FONT *CachedFontLookup(FONT **cache,STYLE *style) {
...
}
void CalcChar(LINE *s,int *x,int *y,int do_draw) { // pas de 'const LINE *' puisqu'on utilise un cache
...
FONT *f=CachedFontLookup(&s->font,&s->style);
...
}
Le compilo est obligé d'aller rechercher s->w, s->h et s->p à chaque fois parce qu'il ne sait pas qu'ils ne sont pas modifiés... Avec un mutable et un 'const LINE *', le compilo pourrait l'optimiser.
Et dans ton exemple, le pointeur n'est pas constant....
Le pointeur est constant dans le sens où toutes les opérations qu'on peut faire dessus (déréférencement, affectation) se comporteront exactement de la même manière. A partir de là, je ne vois pas ce qu'il a de non constant (à part au niveau binaire, mais justement l'utilisateur n'a pas à s'en préoccuper).
Et puis tu m'enerves : le cast de const en rien marche tres bien pour l'implantation bas niveau. C'est pas portable en toute serenite, c'est tout.
Bon, en fait ça me semblait évident qu'une fonction "void f(const foo *x);" n'avait pas le droit de modifier 'x' (à moins de pouvoir y accéder autrement, par exemple via une var globale). Mais le standard C n'a pas l'air d'être clair sur ce point. En gros, ma question est, est-ce que ce code est légal / a un comportement défini (renvoyer 0) dans n'importe quelle implémentation ANSI :
void sub(const int *x) {
*(int *)x=0;
}
int func() {
int x=1;
sub(&x);
return x;
}
En tout cas GCC 3.3.1 n'a pas l'air d'avoir du tout envie de transformer le 'return x' en 'return 1'... (même en déclarant sub() dans un fichier séparé)
Alors si le standard C autorise le code précédent et spécifie qu'il renvoie 0, le hack marche effectivement parfaitement (mais alors 'const' n'est qu'un truc pour empêcher des erreurs); si ce n'est pas le cas, alors la solution que tu proposes a toutes les chances de foirer tôt ou tard en faisant une modification mineure du code...
(Et ceci dit il est de bon ton d'acceder aux champs de ta structure via des macros. Dans ce cas tu n'aurais rien eu a changer 
Il y a clairement et de manière documentée une exception pour les champs marqués "mutable". Alors que si tu te contentes de supprimer les "const" des structures où il y a un cache, tu es obligé à chaque fois de te poser la question "est-ce que la structure est censée être modifiée ou pas par la fonction que j'appelle?" puisqu'il n'y a pas de "const", et tu as du mal à bien faire la différence entre passage d'une valeur et passage d'une valeur qui sera modifiée.
.
niveau efficacité 
Considère qu'un "mutable int" est un wrapper (éventuellement constant) vers un "int" (non-constant), de même qu'un "int *" est un wrapper (éventuellement constant) vers un "int" (non-constant). Je ne vois pas en quoi dans le premier cas, ce serait contraire à la 'philosophie' du "const", alors que dans le second cas non...
