Journal De gcc3 à gcc4 : Un code plus propre ?

Posté par  (site Web personnel) .
Étiquettes : aucune
0
11
avr.
2005
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 ?
  • # Ce n'est pas spécifique à gcc 4

    Posté par  (site Web personnel) . Évalué à 10.

    Gcc4 forcerait les développeurs à coder plus proprement ?
    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  . Évalué à 6.

      Ah noter que l'utilisation par defaut de gcc 4 dans une grande distribution comme FC4 va donner un grand coup de nettoyage pour les logiciels qu'elle inclue.

      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  (site Web personnel) . Évalué à 1.

        Mouai.

        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  . Évalué à 5.

          on parle de gcc, pas de g++, donc pas de c++.

          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  (site Web personnel) . Évalué à 4.

            GCC = GNU Compiler Collection, qui inclue g++.

            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  . Évalué à 4.

            mmhh interressant.
            Quel est la difference avec
            int i;
            i = 'c'

            ?
            • [^] # Re: Ce n'est pas spécifique à gcc 4

              Posté par  . Évalué à 3.

              l'exemple etait un peu stupide, mais si t'as plutot
              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  (site Web personnel) . Évalué à 4.

                ... et tu as un truc monstrueusement pas portable. (big endian, little endian, toussa, ...)
                • [^] # Re: Ce n'est pas spécifique à gcc 4

                  Posté par  . Évalué à 2.

                  pas forcement : (char) *i, ca revient a declarer char *p = i;
                  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  (site Web personnel) . Évalué à 3.

                    > vu que t'ecris qu'un octet ca sera la meme chose sur toute les archi,

                    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  . Évalué à 2.

                      C'est la lecture dans ton example qui n'est pas portable. Si tu lis de la même manière que tu as écrit, tu retomberas toujours sur tes pieds.

                      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  (site Web personnel) . Évalué à 2.

                        Quel est l'intérêt de déclarer un "int *" si c'est pour l'utiliser toujours en "char *" ?

                        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  . Évalué à 2.

                          Si toi tu ne vois pas d'intérêt à cette technique dans le feu de la discussion, n'en deduis pas qu'aucun développeur ne va jamais l'utiliser... On peut par exemple imaginer un pointeur void* qui selon les cas sert en tant que char* ou que int*. C'est d'ailleurs assez courant, et tout à fait portable.

                          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  . Évalué à 2.

                          Bon reprenons :
                          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  . Évalué à 2.

                      Ben c'est portable c'est que t'affiche pas la bonne valeur : ce que t'as voulu modifier c'est le premier octet et pas l'entier.

                      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  . Évalué à 3.

      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.

      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  . É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.
        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  . Évalué à 3.

          Si tout le monde respectait les standards et ne jouait pas avec certaines features, ca serait beaucoup moins problematique...

          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  . Évalué à 7.

            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.

            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  (site Web personnel) . Évalué à 2.

            > Mais effectivement, il me semble que c'était surtout avec le C++.

            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  . Évalué à 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.

            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  . Évalué à 4.

        Tu penses pas que si ils pouvaient ils le ferait ? Après ca depend si tu veux avoir ton compilo strictement compliant une fois tout les 6 ans ou un compilo qui évolue quand même un peu.

        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  . Évalué à 1.

        Pour ceux qui font les distributions ?
        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  . Évalué à 4.

        > Et ils ne pourraient pas faire "tout de suite"

        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.
  • # La solution

    Posté par  . Évalué à 5.

    Plutôt que de contourner le problème avec un CC=gcc32, tu devrais rapporter les bugs à chaque programme qui ne compile pas (sauf si c'est tes programmes, auquel cas corrige les bugs).
    Comme dit plus haut, ça participera à un nettoyage global des logiciels !
    • [^] # Re: La solution

      Posté par  . Évalué à 4.

      Le problème d'Adrien c'est qu'il dit ne pas être "bon" en C... Ce n'est peut-être pas facilement à sa portée de corriger ces bugs...
      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  (site Web personnel) . Évalué à 3.

        Effectivement je connais rien en C, je corrigerai pas les bugs, mais D. Pierre suggérait seulement de les rapporter (bug rapporté à moitié corrigé ???) si j'ai bien compris.
        • [^] # Re: La solution

          Posté par  . Évalué à 3.

          Tout à fait, je ne suggérais que de les rapporter.
          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  . Évalué à 5.

            2- décoder le code source provoquant l'erreur

            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  . Évalué à 2.

              sur les vielles version de g++ (3.3-) c'etait pire, des oublis de << provoquait des internal errors...
            • [^] # Re: La solution

              Posté par  . Évalué à 2.

              La joie des templates en C++... C'est génial non ?
              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  . Évalué à 5.

              "error: no match for 'operator<<' "
              je trouve ca assez explicite.
            • [^] # Re: La solution

              Posté par  . Évalué à 4.

              Je te conseille STLFilt:
              An STL Error Message Decryptor for C++
              http://www.bdsoft.com/tools/stlfilt.html(...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.