Cher journal
Vu que je suis passé en fedora core development, j'ai maintenant gcc4 comme compilateur par défaut. Du coup j'ai des programmes qui compilent plus, j'ai lu que c'est parce que gcc4 est moins tolérant que son grand frère. Le plus souvent c'est "invalid value in lassignment" (en gros la partie de gauche de l'expression lui plaît pas). Pour éviter ça, je rajoute CC=gcc32 à la fin de mes make, mais j'aimerais bien savoir, moi qui suis une bille en C, si c'est facile à corriger comme "erreur de syntaxe". Gcc4 forcerait les développeurs à coder plus proprement ?
Journal De gcc3 à gcc4 : Un code plus propre ?
11
avr.
2005
# Ce n'est pas spécifique à gcc 4
Posté par Benoît Déchamps (site web personnel) . Évalué à 10.
Ce n'est pas uniquement le cas de gcc4, c'est toujours le cas entre chaque release majeure. Des structures plus ou moins incorrectes qui étaient tolérées dans les versions précédentes ne sont plus acceptées dans les nouvelles versions. Par exemple, il n'est pas possible de compiler openoffice.org 1.1 avec gcc 3.4, l'utilisation de gcc 3.3 ou plus ancien est obligatoire.
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par Pierre Tramo . Évalué à 6.
Il deviendra de mauvais aloy de sortir un logiciel qui ne compile pas sous FC4, et ça va améliorer la qualité globale des logiciels.
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par Philippe F (site web personnel) . Évalué à 1.
J'ai pas le niveau pour comprendre l'interet de toutes les exigences, qui il est vrai sont la pour respecter le standard C++.
Mais si c'est pour que les // ne soient pas supportes en C parce que le standard l'interdit, est-ce que ca vaut le coup. Je me demande si les exigences de compatbilites ne sont pas de ce niveau la.
Le C++ reste un langage incroyablement complexe. Il reste cependant possible de coder en l'utilisant simplement. J'espere que ces 'mises au standard" ne vont pas retirer cette possiblite.
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par M . Évalué à 5.
De plus les commentaire a la C sont suporte dans le standard C99, donc pas de probleme...
Le probleme viennet plus de certaines magouilles tel que :
int i;
(char)i = 'c'
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
D'ailleurs, on peut très bien compilé du C++ avec gcc, en passant les options kivontbien.
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par Pierre . Évalué à 4.
Quel est la difference avec
int i;
i = 'c'
?
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par M . Évalué à 3.
int *i;
alors avec (char)*i = 'c' tu ecris que 1 octet en memoire
et avec *i = 'c' tu ecris 4 octets ( c est transforme en int)
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par M . Évalué à 2.
Apres vu que t'ecris qu'un octet ca sera la meme chose sur toute les archi, puis si tu ecris par par block de 32 bits (c'est bien pour ca qu'on avais choisi un int*) alors tu peux toujours utiliser des macro du type cpu_le32, htonl qui te fond la conversion suivant les archi...
D'ailleur si cela avait avoir avec la portabilite ca ferait longtemps que ca serait corrige dans certaines distributions multi-archi.
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Ben justement non. Tu écrit un octet sur 4, la question, c'est si tu écris sur les bits de poids fort ou sur les bits de poids faibles, et ça, ça dépends de l'endianness de ta machine. Exemple:
$ cat endian.c
#include <stdio.h>
int main() {
int x = 0x01020304;
int * px = &x;
printf("%x\n", *px);
*(char *)px = 'a';
printf("%x\n", *px);
}
$ uname -a
SunOS asti 5.9 Generic_117171-09 sun4u sparc SUNW,Sun-Fire-V240
$ /usr/local/soft/gcc/3.0.2/bin/gcc endian.c
$ ./a.out
1020304
61020304
$ uname -a
Linux ecrins 2.4.27-2-k7-smp #1 SMP Thu Jan 20 11:33:07 JST 2005 i686 GNU/Linux
$ /usr/local/soft/gcc/3.0.2/bin/gcc endian.c
$ ./a.out
1020304
1020361
> D'ailleur si cela avait avoir avec la portabilite ca ferait longtemps que ca serait corrige
> dans certaines distributions multi-archi.
En C ANSI, tu peux très bien faire du code endian-dependant (il suffit d'avoir droit aux cast de pointeurs). Le C *peut* être portable, si on ne fait pas de conneries avec, mais c'est pas la philosophie du language de t'empêcher d'en faire.
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par calandoa . Évalué à 2.
int toto = 1234;
int *ptr = &toto;
*(char*)ptr = 'Z';
Maintenant si tu ne fait que des « char read = *(char*) ptr; » tu trouveras toujours des 'Z', quelque soit l'architecture... Question lisibilité, c'est pas génial, mais portabilité il n'y a pas de problèmes, à condition de savoir ce que l'on fait.
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
L'intérêt du cast ici, c'est de pouvoir accéder à la même valeur de plusieurs façons. Il se trouve que c'est pas portable.
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par calandoa . Évalué à 2.
Je vois personnellement encore moins d'intérêt à écrire en tant que char* et à lire en tant qu'int*. Mais bon, je me garderais bien de prétendre connaître toutes les techniques utilisables en C, portables ou non :^)...
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par M . Évalué à 2.
Imaginons que j'ai une zone de memoire contenant des donnees :
la taille coder sur 1 octet,
l'info y est coder sur 2 octets
l'info z est coder sur 4 octets
int *i = debut de la zone memoire
(char)*i = taille;
(uint16)*i = htons(y);
*i = htonl(z);
Bon apres tu utilise une structure packed si les champs sont fixe, mais c'est pas toujours le cas. La sol propre est de declarer 3 pointeur, un pour chaque type...
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par M . Évalué à 2.
Donc si t'as char *p = px; et t'affiche le contenu de *p ca sera le meme...
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par Jllc . Évalué à 3.
Et ils ne pourraient pas faire "tout de suite" une version moins tolérantes, plutôt que changer un peu à chaque release ? Il y a déjà des projets qui ne compilent qu'avec un Gcc 2.XX ou 3.XX, s'il faut encore différencier entre gcc3.XX et Gcc 4.XX, j'imagine le casse-tête pour ceux qui font des distributions.
Sans compter la compatibilité des fichiers binaires. On a beau "avoir les sources", il y a des gens qui n'ont pas envi de recompiler un logiciel pour une distribution un peu "ancienne" (terme particulièrement relatif), ni envie de mettre à jour la distribution en question.
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par M . Évalué à 3.
Si tout le monde respectait les standards et ne jouait pas avec certaines features, ca serait beaucoup moins problematique...
Par contre pour la comp binaire tu parle de quoi ?
Pour le C il me semble que ca pas changer depuis tres longtemps, pour le c++ ca commence a etre bien stabilisee...
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par Jllc . Évalué à 3.
Je comprends bien le problème, mais ce que je demandais, c'est pourquoi les changement apportés entre Gcc 3 et Gcc 4 n'ont pas été fait "tout de suite" pour la version 3. J'ai l'impression que son adoption est encore "relativement" récente, et il va falloir déjà faire des changement importants au niveau des codes sources. Remarquez, ce n'est pas mon problème, je n'ai plus fait de C ou C++ depuis ma sortie de l'école, mais je pense aux développeurs.
Par contre pour la comp binaire tu parle de quoi ?
Pour le C il me semble que ca pas changer depuis tres longtemps, pour le c++ ca commence a etre bien stabilisee...
Des changements d'Abi lors de la sortie de Gcc 3 qui posaient problème pour lier des exécutable et des bibliothèques compilés avec différentes versions de gcc. Mais effectivement, il me semble que c'était surtout avec le C++.
Mais comme je ne maitrise pas du tout ces problèmes, je dis peut être des bétises.
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par M . Évalué à 7.
Pour laisser le temps aux developpeurs de corriger les pb :
gcc 3 : attention : use of cast expressions as lvalues is deprecated
gcc 4 : error: invalid lvalue in assignment
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Tout a fait. L'ABI C++ a changé de 2.95 à 3.0, puis de 3.1 à 3.2 (3.0 a 3.1, je sais plus), mais elle s'est stabilisée depuis la 3.2 sur architecture Intel au moins.
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par fabb . Évalué à 3.
Il faut relativiser. FC4 test 1 et test 2 (qui doit sortir aujourd'hui) utilise déjà gcc4.
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par ckyl . Évalué à 4.
Pour rappel gcc n'est toujours pas entièrement compatible C99... http://gcc.gnu.org/c99status.html(...)
Mais je suis sur que gcc accepte les contributeurs. Au passage c'est pas gcc qui fait chier c'est les mecs qui écrivent du code pas standard/mauvais et qui de plus ne le mette pas à jour.
C'est un peu comme geuler sur firefox par ce qu'il n'implémente pas tout de suite, et sans aucun bug, une recommandation X ou Y et de leur geuler ensuite dessus quand des webmasters ont utilisés des tricks qui tiraient parti des bugs de firefox...
Note que les specs de Java vont dans ton sens, on implémente tout ou rien, mais c'est très décrié ici car "incompatible avec le libre". Faudrait savoir...
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par Pinaraf . Évalué à 1.
C'est très simple : ho ça compile pas ! Hop on googlise, avec un peu de chance on trouve le patch qui va bien, sinon on écrit le patch et/ou on rapporte le bug. Et comme on est cencé suivre les paquets quand on est mainteneur, ben on peut voir les problèmes avant la version finale du programme (par exemple sur les versions beta) et ainsi voir les problèmes corrigés.
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par fabb . Évalué à 4.
C'est vrai ça !
Pourquoi Linux 2.6 n'est pas sorti tout de suite au-lieu de sortir après Linux 1.0, 1.2, 2.0, 2.2, 2.4.
D'ailleurs je pense que Linux devrait dès maintenant travailler sur Linux 8.0 au-lieu de nous faire chier avec les version 2.8, 3.0, etc, etc, etc, etc.
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par Jllc . Évalué à 2.
Il doit même être plus simple de laisser tomber des cas qui ne devrait pas être pris en charge.
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par M . Évalué à 2.
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par Jllc . Évalué à 3.
On parle au début de mauvaises habitudes qu'on pris les programmeurs et qui ne sont plus tolérées, mais on fait référence à une norme, de 1999 si j'ai bien compris.
Une mauvaise habitude et un changement de norme ne sont pas du tout la même chose !
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par Adrien BUSTANY (site web personnel) . Évalué à 1.
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par fabb . Évalué à 3.
Le noyau de la branche de développement de Fedora est compilé avec gcc4. Regardes si tu y trouves ton bonneur :
http://fr2.rpmfind.net/linux/fedora/core/development/SRPMS/(...) (src.rpm)
http://cvs.fedora.redhat.com/viewcvs/devel/kernel/(...) (cvs)
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par Adrien BUSTANY (site web personnel) . Évalué à 1.
[^] # Re: Ce n'est pas spécifique à gcc 4
Posté par ribwund . Évalué à 2.
A mon avis ton patch il est dans le broken-out d'Andrew.
# La solution
Posté par Pinaraf . Évalué à 5.
Comme dit plus haut, ça participera à un nettoyage global des logiciels !
[^] # Re: La solution
Posté par galatea842 . Évalué à 4.
D'autant plus que "parfois" les exmples que l'on trouve facilement sur le net ne sont pas exampt de tout bug... Les compilateurs étant parfois "laxistes" les "pros" du C peuvent transmettent des erreurs à leurs disciples...
Donc une solution est dans ce cas qu'un crack (que je ne suis pas :( ) produisent une documentation sur ces fameux bugs qu'il est temps de ne plus produire...
(bon je n'ai pas regardé la doc de GCC4 peut-être y a t il déjà une telle documentation)
[^] # Re: La solution
Posté par Adrien BUSTANY (site web personnel) . Évalué à 3.
[^] # Re: La solution
Posté par Pinaraf . Évalué à 3.
Les corriger, c'est loin d'être à la portée de tout le monde ! En effet, ça implique :
1- comprendre l'erreur
2- décoder le code source provoquant l'erreur
3- corriger l'erreur sans engendrer des bugs supplémentaires
Et faire ça sur tous les logiciels c'est pas pratique.
[^] # Re: La solution
Posté par ckyl . Évalué à 5.
Pourtant g++ est une merveille pour te sortir un message d'erreur intelligible. D'ailleurs je conseil très fortement l'utilisation de la locale française pour aider encore un petit peu plus.
Exemple: http://euterpe.unice.fr/~mathieuc/gpp.txt(...)
Simplement une exception qui avait pas redefinie << on fait difficilement plus lisible n'est ce pas ?
Attention ce message contient une pointe d'ironie.
[^] # Re: La solution
Posté par M . Évalué à 2.
[^] # Re: La solution
Posté par Pinaraf . Évalué à 2.
Ce sujet n'est pas traîté par mon vieux bouquin sur le C++ (pas plus que les exceptions d'ailleurs, ni les classes pratiques comme std::string ou std::vector)
[^] # Re: La solution
Posté par Guillaume Chevallereau . Évalué à 5.
je trouve ca assez explicite.
[^] # Re: La solution
Posté par C2RIK . Évalué à 4.
An STL Error Message Decryptor for C++
http://www.bdsoft.com/tools/stlfilt.html(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.