RAAAAAAAAAHHHHHHHHHHHHHHH BORDEL DE MERDE DE GCC!!!! - Page 1

et de ces putain de connards qui virent des fonctionnalites utiles...
RRRRRHHHHHHHHHHHAAAAAAAAAAHHHHHHH PUTAIN DE.......................................

http://gcc.gnu.org/ml/gcc-bugs/2003-10/msg02580.html

mais putain ces raisons... c'est completement CON!!!! quelle bande d'encules! tout ce qu'ils font avec ca c'est empoisonner la vie des gens...
asdfliuhalwefuasdfasjfdtyqwde68t249t7pea glfha ds8f9ya379253tar9oihdfsdfuSGYf^O*T(#P*TRIHOSDLFbshfdgaoifuoAYF083yh;orjuesefds;lifjk!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!



j'ai envie de les trucider, de les torturer, de les fouetter, de les.... GGGGGRRRRRRRMMMMMMMMMMFFFFFFFFFFFFFF !!!

dans la 3.3 "deprecated"
pis dans la 3.4.. "removed" ^

PUTAIN!!!!!

• sBibi pas content... groumf...


(au cas ou ca serait pas clair, c'est pke ces trou du cul ont decide de virer la concatenation de l'extension __FUNCTION__ de gcc avec des strings dans la version 3.4 de gcc, et deprecated dans la 3.3... tain mais n'importe quoi... quelle bande de connards...)

Bof... ça sert à rien

Je suis entièrement d'accord avec toi! Cf. aussi http://b15.ezboard.com/ftichessteamhqfrm13.showMessage?topicID=453.topic.
Je peux réverser ça pour TIGCC et te faire parvenir un patch à appliquer à FSF GCC pour réverser ça, mais c'est tout ce que je peux faire, moi.
Vivement un fork de GCC:
* sans copyright assignments!
* avec une attitude pro-extensions comme dans les "beaux vieux temps"!
* avec un système de patches "no objections means go ahead" (à la KDE) plutôt que des patches qui attendent des mois que quelqu'un bouge son c*l pour les "review"er!
Alors, personne pour m'aider à mettre en place un tel fork?

Je ne crois pas, non.

tiens

Avoiding use of GNU extensions whenever possible is encouraged;
even if you don't care whether the program is portable to other
compilers, the extensions tend not to have well-defined semantics
compared to the rest of the language, so it is hard to tell whether the program is correct or not.

Bref les mainteneurs de GCC découragent d'utilise les extentions GNU

Ça montre à quel point le projet a dégénéré.
D'ailleurs, c'est surtout ce gros dictateur de Zack Weinberg qui se permet de dire ça au nom de tous les mainteneurs. C'est vraiment un gros vandale: il n'arrête pas de vouloir tout supprimer et de prétendre que ça fait avancer le projet GCC.

Et il a bien raison. Par exemple les "multi-line string literals" rendent les parsings simplifiés plus difficiles, en plus d'avoir des sémantiques un peu vaseuses selon les plateformes...

Et puis les extensions sont avant tout des tentatives expérimentales et peuvent avoir des effets pervers qui font qu'elles sont réservées à des usages spécifiques... Même si c'est évident que certaines extensions sont clairement utiles et ne font rien de mal, il y en a qui sont à éviter pour pas mal de raisons

Pollux
: Et il a bien raison. Par exemple les "multi-line string literals" rendent les parsings simplifiés plus difficiles, en plus d'avoir des sémantiques un peu vaseuses selon les plateformes...

Je ne suis pas d'accord! TIGCC continue à les gérer en tout cas, et je n'ai aucune intention de changer ça. Et ça n'a rien à voir avec du "parsing simplifié", ça a été supprimé parce que les messages d'erreurs ne donnaient pas toujours la bonne ligne pour les guillemets manquants. Comme si de tels détails au niveau des diagnostics justifiaient la suppression d'une extension utile.

Et puis les extensions sont avant tout des tentatives expérimentales et peuvent avoir des effets pervers qui font qu'elles sont réservées à des usages spécifiques... Même si c'est évident que certaines extensions sont clairement utiles et ne font rien de mal, il y en a qui sont à éviter pour pas mal de raisons

Tant pis si elles ont des "effets pervers" dans certains cas. Tant qu'elles marchent dans les cas où elles apparaissent en pratique, on s'en fiche. Ce n'est clairement pas une raison de détruire (empêcher de compiler) tous les logiciels qui utilisent cette extension d'une manière qui fonctionne très bien.

Kevin Kofler
:

Pollux
: Et il a bien raison. Par exemple les "multi-line string literals" rendent les parsings simplifiés plus difficiles, en plus d'avoir des sémantiques un peu vaseuses selon les plateformes...

Je ne suis pas d'accord! TIGCC continue à les gérer en tout cas, et je n'ai aucune intention, de changer ça.

Je suis d'accord pour que TIGCC continue à les gérer (notamment parce que c'est le seul moyen de programmer en ASM de manière pas trop horrible avec TIGCC, même si c pas génial qd même), et puis surtout il n'y a aucun prog utilisant de parseur simplifié donc le problème est réglé. Ce n'est pas du tout le cas sur PC...

Et puis les extensions sont avant tout des tentatives expérimentales et peuvent avoir des effets pervers qui font qu'elles sont réservées à des usages spécifiques... Même si c'est évident que certaines extensions sont clairement utiles et ne font rien de mal, il y en a qui sont à éviter pour pas mal de raisons

Tant pis si elles ont des "effets pervers" dans certains cas. Tant qu'elles marchent dans les cas où elles apparaissent en pratique, on s'en fiche. Ce n'est clairement pas une raison de détruire (empêcher de compiler) tous les logiciels qui utilisent cette extension d'une manière qui fonctionne très bien.

Une extension marquée expérimentale n'a pas à être supportée, c'est sa nature même Et des raisons de supprimer les "features" inutiles et même néfastes, il y en a plein, par exemple la maintenabilité du code. C'est d'autant plus difficile de maintenir le code que :
* ce qu'on manipule n'a pas une sémantique très claire, donc on ne sait pas trop si une modif est valide
* ça accroît la taille du code
* les features inutilisées ne seront pas détectées par les tests de régression
* mieux vaut supprimer une feature plutôt que de la casser pendant des mois sans que personne ne s'en rende compte...

tain aussi dans les "features" de gcc 3.4/3.5, ya plus de cast lvalues
trop fort
je les aime ces gentils mainteneurs de gcc , surtout et en particulier ceux qui decident de rendre ces trucs la deprecated et de les virer
a un point tel que si j'en croise un dans la rue je l'etripe...

Pollux:

Et des raisons de supprimer les "features" inutiles et même néfastes, il y en a plein, par exemple la maintenabilité du code.

tu m'excusera, mais dans le cas de __FUNCTION__, et de pas mal d'autres extensions, tu peux m'expliquer l'interet d'en virer une partie? ils ont pas interet a le virer tout court, ca serait vraiment encore plus abruti et borne que de virer la concatenation avec des strings... et franchement si ils font ca et qu'il y a pas de compilateur equivalent a gcc qui aie pas des devs aussi cons, j'utilise plus gcc et je dev plus que sous windows...

ok ils virent la concat de __FUNCTION__ avec des strings...
1- ca rend le code plus complexe, dans le cas d'une utilisation de ce genre:

#define LOG(s...) kr_log_printf("[" PV_MODULE_NAME "::" __FILE__ "::" STRINGIFY(__LINE__) "::" __FUNCTION__ "] " s)

utilisee comme ca:

LOG("bande de %s", "connards");

c'est sur que ca optimise vachement d'avoir a faire:

#define LOG(s...) kr_log_printf(__FUNCTION__, PV_MODULE_NAME, __FILE__, __LINE__, s)



ce qui me fait le plus chier avec ca c'est que non seulement ca allourdit le passage de parametres et la fonction de log elle meme, mais ca vire completement le concept d'une fonction de log_printf qui devrait marcher sans avoir a se servir de la macro LOG, qui a la base etait la que pour avoir une sorte de norme dans les msg de logs affiches...

surtout que cet exemple la est pas celui que j'utilise reellement (j'aimerai bien) pke VC++ supporte pas les parametres va_arg style pour les macros. (si quelqu'un sait comment faire je lui offre une nuit sm gratuite

surtout que l'excuse d' "optimiser" le tableau de strings genere par le compilateur est meme pas valable... tu gagne une chiure de blatte pour la taille du prog et la fonction de log doit faire des concatenations completement inutiles a chaque appel alors que ca aurait tres bien pu etre fait a la compilation, pour un temps de compil supplementaire completement minable, voire negatif...

* ça accroît la taille du code

dans ce cas la, ca la decroit, et de bcp si tu log massivement.
le seul truc que ca accroit, c'est eventuellement la taille de l'exe, et de facon negligeable.
au final, ca fait plus chier le programmeur qu'autre chose... genial non?

* mieux vaut supprimer une feature plutôt que de la casser pendant des mois sans que personne ne s'en rende compte...

si la feature est utile est tres utilisee (comme c'est le cas la), mieux vaut ne pas la supprimer ni la casser du tout...

C'est vraiment un gros vandale: il n'arrête pas de vouloir tout supprimer et de prétendre que ça fait avancer le projet GCC.

on appelle aussi ca un trou du cul et un gros connard.

Je suis entièrement d'accord avec toi!

wow, pour une fois

Je peux réverser ça pour TIGCC et te faire parvenir un patch à appliquer à FSF GCC pour réverser ça, mais c'est tout ce que je peux faire, moi.

merci de proposer, je sais pas trop comment ca se presente un patch pour ca.. ca patche l'exe ou les sources? (patcher l'exe pour ce genre de trucs ca doit etre relativement tendu a faire )
pke le seul truc qui me fait chier dans l'histoire c'est que notre truc soit pas compilable avec une version "normale" de gcc, que les gars qui veulent le recompiler aient besoin de patcher leur gcc. remarque on peut tjrs fournir le compilo avec, m'enfin bon... c'est gore.
un truc que j'ai pense faire pour ce probleme specifique (le __FUNCTION__), c'est de reutiliser le preprocesseur qu'on est en train de faire pour les scripts de VM qui est en fait un preprocesseur C, de l'utiliser en lieu et place du preproc utilise par gcc (y doit y avoir moyen de forcer un preprocesseur dans les options de compil de gcc dans le makefile non?), qu'il preprocess normalement et a la fin une passe pour manuellement remplacer tous les __FUNCTION__, comme ca gcc s'en occupe plus.
enfin bon c'est gore aussi

Alors, personne pour m'aider à mettre en place un tel fork?

j'ai deja pas assez de temps pour coder ce que je devrais coder, donc pour ma part ca va pas etre possible.

j'ai deja pas assez de temps pour coder ce que je devrais coder, donc pour ma part ca va pas etre possible.

#sifflote#

chut
/nick sBibi`Q3`cpma

sBibi :
tain aussi dans les "features" de gcc 3.4/3.5, ya plus de cast lvalues
trop fort
je les aime ces gentils mainteneurs de gcc , surtout et en particulier ceux qui decident de rendre ces trucs la deprecated et de les virer
a un point tel que si j'en croise un dans la rue je l'etripe...

Pollux:

Et des raisons de supprimer les "features" inutiles et même néfastes, il y en a plein, par exemple la maintenabilité du code.

tu m'excusera, mais dans le cas de __FUNCTION__, et de pas mal d'autres extensions, tu peux m'expliquer l'interet d'en virer une partie? ils ont pas interet a le virer tout court, ca serait vraiment encore plus abruti et borne que de virer la concatenation avec des strings... et franchement si ils font ca et qu'il y a pas de compilateur equivalent a gcc qui aie pas des devs aussi cons, j'utilise plus gcc et je dev plus que sous windows...

ok ils virent la concat de __FUNCTION__ avec des strings...
1- ca rend le code plus complexe, dans le cas d'une utilisation de ce genre:

#define LOG(s...) kr_log_printf("[" PV_MODULE_NAME "::" __FILE__ "::" STRINGIFY(__LINE__) "::" __FUNCTION__ "] " s)

utilisee comme ca:

LOG("bande de %s", "connards");

c'est sur que ca optimise vachement d'avoir a faire:

#define LOG(s...) kr_log_printf(__FUNCTION__, PV_MODULE_NAME, __FILE__, __LINE__, s)



ce qui me fait le plus chier avec ca c'est que non seulement ca allourdit le passage de parametres et la fonction de log elle meme, mais ca vire completement le concept d'une fonction de log_printf qui devrait marcher sans avoir a se servir de la macro LOG, qui a la base etait la que pour avoir une sorte de norme dans les msg de logs affiches...

surtout que cet exemple la est pas celui que j'utilise reellement (j'aimerai bien) pke VC++ supporte pas les parametres va_arg style pour les macros. (si quelqu'un sait comment faire je lui offre une nuit sm gratuite
surtout que l'excuse d' "optimiser" le tableau de strings genere par le compilateur est meme pas valable... tu gagne une chiure de blatte pour la taille du prog et la fonction de log doit faire des concatenations completement inutiles a chaque appel alors que ca aurait tres bien pu etre fait a la compilation, pour un temps de compil supplementaire completement minable, voire negatif...

En l'occurrence, ton extension a l'air assez utile, oui... Surtout que comme c'est le compilo qui doit de toute façon se charger de la concaténation des strings (et pas le préprocesseur), je ne vois pas l'intérêt qu'ils auraient à l'enlever

Mon post était surtout pour répondre au post de Kevin qui disait qu'il n'aimait pas le fait que GCC deprecate des trucs (et/ou les enlève)... Pour l'exemple des multi-line string literals (dont il s'est plaint des dizaines de fois), je pense que les mainteneurs de GCC avaient raison. Et il y a pas mal d'extensions un peu "expérimentales" et bancales qui doivent être dans le même cas. Celle dont tu parles n'est pas dans ce cas-là, puisqu'elle a le mérite d'avoir une sémantique très claire...

A moins que &__FUNCTION__ soit censé être légal, et dans ce cas-là les mainteneurs de GCC n'auraient pas tout à fait tort... (mais alors ce serait la définition standard de __FUNCTION__ qui serait n'importe quoi)

* ça accroît la taille du code

dans ce cas la, ca la decroit, et de bcp si tu log massivement.
le seul truc que ca accroit, c'est eventuellement la taille de l'exe, et de facon negligeable. au final, ca fait plus chier le programmeur qu'autre chose... genial non?

Je parlais du code du compilo... Mais encore une fois, cette extension doit vraiment être simple à implémenter, donc elle n'est pas visée par ce que je dis.

* mieux vaut supprimer une feature plutôt que de la casser pendant des mois sans que personne ne s'en rende compte...

si la feature est utile est tres utilisee (comme c'est le cas la), mieux vaut ne pas la supprimer ni la casser du tout...

vi... mais ce n'est pas le cas des multi-line string literals, par exemple.

En l'occurrence, ton extension a l'air assez utile, oui...

ya la meme sous VS .NET 2003 soit dit en passant (au cas ou tu serais pas au courant ) mais visiblement implementee sous forme d'une macro un peu... "speciale"
enfin je sais pas exactement comment c'est implemente, mais le preproc rentre dans un #ifdef __FUNCTION__, en fait c'est peut etre juste une macro vide declaree pour dire que __FUNCTION__ est gere, mais si c'etait ca, le preproc remplacerait toutes les occurences de __FUNCTION__, enfin y a un truc qui m'echappe, ou bien alors effectivement c'est traite comme un cas a part par le preproc, et il remplace tout avec une passe supplementaire, ou apres qu'il aie expanse toutes les autres macros... chais pas..

mais ce n'est pas le cas des multi-line string literals

heu ok soit, si tu le dis , en code ca donne quoi les multi-line string literals?

c'est quand meme pas ca nan?

printf("truc "
"machin "
"bidule "
"marmotte\n");

??

En l'occurrence, ton extension a l'air assez utile, oui...

ya la meme sous VS .NET 2003 soit dit en passant (au cas ou tu serais pas au courant ) mais visiblement implementee sous forme d'une macro un peu... "speciale" enfin je sais pas exactement comment c'est implemente, mais le preproc rentre dans un #ifdef __FUNCTION__, en fait c'est peut etre juste une macro vide declaree pour dire que __FUNCTION__ est gere, mais si c'etait ca, le preproc remplacerait toutes les occurences de __FUNCTION__, enfin y a un truc qui m'echappe, ou bien alors effectivement c'est traite comme un cas a part par le preproc, et il remplace tout avec une passe supplementaire, ou apres qu'il aie expanse toutes les autres macros... chais pas..

J'ai pas encore eu besoin d'utiliser __FUNCTION__, donc je suis pas au courant...

mais ce n'est pas le cas des multi-line string literals

heu ok soit, si tu le dis , en code ca donne quoi les multi-line string literals?

c'est quand meme pas ca nan?

printf("truc "
"machin "
"bidule "
"marmotte\n");

??

Non, c'est

printf("truc
machin
bidule
marmotte\n");

qui est bien plus gore (pbs avec l'indentation et les retours à la ligne qui dépendent de la plateforme, on ne peut pas déterminer si on est dans une chaîne sans avoir lu tout le fichier depuis le début, etc...)

J'ai pas encore eu besoin d'utiliser __FUNCTION__, donc je suis pas au courant...

ah, ok c'etait pas dans VC++6, c'est arrive juste apres, et c'est quand meme super pratique si tu veux faire un profiler temps reel ou un logger, ou d'autres trucs... comme __FILE__, __LINE__, __DATE__, etc..

arf ok... je savais pas que c'etait gere ca
oue effectivement c'est un peu crade

sBibi
:

J'ai pas encore eu besoin d'utiliser __FUNCTION__, donc je suis pas au courant...

ah, ok c'etait pas dans VC++6, c'est arrive juste apres, et c'est quand meme super pratique si tu veux faire un profiler temps reel ou un logger, ou d'autres trucs... comme __FILE__, __LINE__, __DATE__, etc..

Oué, VC++ est pourri dans plein de domaines...

arf ok... je savais pas que c'etait gere ca oue effectivement c'est un peu crade

En gros, ça ne sert que pour l'asm, et encore parce que GCC utilise des chaînes de caractères pour ça... (j'imagine qu'il a bien dû y avoir qques rigolos pour l'utiliser pour afficher le "Usage : blabla" classique, mais c'est très con )

sBibi :
tain aussi dans les "features" de gcc 3.4/3.5, ya plus de cast lvalues
trop fort

Oui, je m'en suis plaint moi aussi. Dans ce cas, je suis obligé de réverser le patch pour TIGCC, parce que TIGCCLIB en a besoin. (C'est soit ça, soit une violation des règles d'aliasing à la noix. )

je les aime ces gentils mainteneurs de gcc , surtout et en particulier ceux qui decident de rendre ces trucs la deprecated et de les virer a un point tel que si j'en croise un dans la rue je l'etripe...

Je te comprends parfaitement...

C'est vraiment un gros vandale: il n'arrête pas de vouloir tout supprimer et de prétendre que ça fait avancer le projet GCC.

on appelle aussi ca un trou du cul et un gros connard.

Je suis entièrement d'accord avec toi!

wow, pour une fois

Je peux réverser ça pour TIGCC et te faire parvenir un patch à appliquer à FSF GCC pour réverser ça, mais c'est tout ce que je peux faire, moi.

merci de proposer, je sais pas trop comment ca se presente un patch pour ca.. ca patche l'exe ou les sources? (patcher l'exe pour ce genre de trucs ca doit etre relativement tendu a faire )

Oui, on est obligé de patcher les sources.

Et je ne peux pas non plus te garantir de faire ce patch immédiatement. Tu en as besoin dans quels délais?

pke le seul truc qui me fait chier dans l'histoire c'est que notre truc soit pas compilable avec une version "normale" de gcc, que les gars qui veulent le recompiler aient besoin de patcher leur gcc. remarque on peut tjrs fournir le compilo avec, m'enfin bon... c'est gore.

C'est ce que je vais finir par faire avec TIGCC s'ils cassent la compilation de notre linker en continuant comme ça. Dans notre cas, on a de toute façon déjà besoin des sources de GCC pour compiler TIGCC, donc autant s'en servir pour compiler aussi un GCC non-cassé pour le host. Mais dans ton cas, c'est plus délicat en effet.

un truc que j'ai pense faire pour ce probleme specifique (le __FUNCTION__), c'est de reutiliser le preprocesseur qu'on est en train de faire pour les scripts de VM qui est en fait un preprocesseur C, de l'utiliser en lieu et place du preproc utilise par gcc (y doit y avoir moyen de forcer un preprocesseur dans les options de compil de gcc dans le makefile non?), qu'il preprocess normalement et a la fin une passe pour manuellement remplacer tous les __FUNCTION__, comme ca gcc s'en occupe plus.

C'est une solution.
Mais il faut faire ça en 2 étapes: préprocesser d'abord en un fichier, puis appeler gcc (préprocesse encore une fois) ou gcc -preprocessed (ne repréprocesse pas, mais, d'après ce que je sais, attend la sortie par le préprocesseur GNU avec les numéros de ligne etc qu'il rajoute). On ne peut pas changer le préprocesseur appelé par GCC parce qu'il est interne, on peut juste empêcher qu'il soit appelé.

Alors, personne pour m'aider à mettre en place un tel fork?

j'ai deja pas assez de temps pour coder ce que je devrais coder, donc pour ma part ca va pas etre possible.

OK. C'est le problème le plus grand. Ceux qui sont intéressés par un compilateur qui "fonctionne" ne sont en général pas ceux qui ont le temps de s'y plonger...

Pollux
: Mon post était surtout pour répondre au post de Kevin qui disait qu'il n'aimait pas le fait que GCC deprecate des trucs (et/ou les enlève)... Pour l'exemple des multi-line string literals (dont il s'est plaint des dizaines de fois),

Pas seulement moi! Pas mal d'utilisateurs de TIGCC aussi, et des commentaires sur Slashdot aussi (à chaque newsitem parlant de GCC!).

je pense que les mainteneurs de GCC avaient raison.

Et il y a pas mal d'extensions un peu "expérimentales" et bancales qui doivent être dans le même cas. Celle dont tu parles n'est pas dans ce cas-là, puisqu'elle a le mérite d'avoir une sémantique très claire...

Et les chaînes de caractères multi-lignes, elles n'ont pas une sémantique très claire???

* ça accroît la taille du code

dans ce cas la, ca la decroit, et de bcp si tu log massivement.
le seul truc que ca accroit, c'est eventuellement la taille de l'exe, et de facon negligeable. au final, ca fait plus chier le programmeur qu'autre chose... genial non?

Je parlais du code du compilo...

La taille et la vitesse du compilateur ne sont pas ce qu'il y a de plus important... La taille et la vitesse du code produit sont beaucoup plus importants.

si la feature est utile est tres utilisee (comme c'est le cas la), mieux vaut ne pas la supprimer ni la casser du tout...

vi... mais ce n'est pas le cas des multi-line string literals, par exemple.

Hein???
Cette extension était (et est toujours dans le cas de TIGCC ) utilisée dans des centaines de sources! Même le noyau Linux les utilisait dans tous les sens!

sBibi
:

En l'occurrence, ton extension a l'air assez utile, oui...

ya la meme sous VS .NET 2003 soit dit en passant (au cas ou tu serais pas au courant ) mais visiblement implementee sous forme d'une macro un peu... "speciale" enfin je sais pas exactement comment c'est implemente, mais le preproc rentre dans un #ifdef __FUNCTION__, en fait c'est peut etre juste une macro vide declaree pour dire que __FUNCTION__ est gere, mais si c'etait ca, le preproc remplacerait toutes les occurences de __FUNCTION__, enfin y a un truc qui m'echappe, ou bien alors effectivement c'est traite comme un cas a part par le preproc, et il remplace tout avec une passe supplementaire, ou apres qu'il aie expanse toutes les autres macros... chais pas..

Peut-être:
#define __FUNCTION__ __FUNCTION__
tout simplement.

Pollux :
Non, c'est

printf("truc
machin
bidule
marmotte\n");

qui est bien plus gore (pbs avec l'indentation

Il suffit de savoir qu'il ne faut pas indenter à l'intérieur de la chaîne (normal, c'est une chaîne de caractères, donc le whitespace est significatif).

et les retours à la ligne qui dépendent de la plateforme,

On utilise les retours à la ligne de la plateforme sur laquelle on travaille. C'est bon dans pratiquement tous les cas. (Surtout parce que des trucs comme printf acceptent à la fois \n et \r\n sans problèmes normalement.)

on ne peut pas déterminer si on est dans une chaîne sans avoir lu tout le fichier depuis le début,

Et alors?
On ne peut pas non plus déterminer si on est dans un commentaire /**/ sans avoir lu tout le fichier depuis le début (ou depuis le dernier */ dans certains cas).

Kevin Kofler :
Oui, je m'en suis plaint moi aussi. Dans ce cas, je suis obligé de réverser le patch pour TIGCC, parce que TIGCCLIB en a besoin. (C'est soit ça, soit une violation des règles d'aliasing à la noix. )

ah j'avais pas ete voir tes liens dans ton premier post... oui effectivement...
enfin un truc que je me demande quand meme... a part les "mainteneurs" de gcc, j'ai vu que des echos negatifs sur ces trucs la... ils s'en foutent de l'avis des gens qui utilisent leur compilo? c'est pke ya rien d'autre de convenable sous nux alors ils se genent pas?

Oui, on est obligé de patcher les sources.

ok..

Et je ne peux pas non plus te garantir de faire ce patch immédiatement. Tu en as besoin dans quels délais?

non mais te prend pas la tete, la j'en ai pas _besoin_. soit on code un truc pas compilable par les prochaines versions de gcc, soit on fait en sorte que y aie aucun collage de chaines avec des __FUNCTION__ (c'est sans doute le truc le plus chiant et qui alourdit), soit on fait ce que j'ai fait temporairement, cad gerer gcc comme un compilo qui ne gere pas le __FUNCTION__, cad un:

#if (!defined(__FUNCTION__))
#define __FUNCTION__ "???"
#endif

au lieu d'un (ce qu'il y avait avant qu'on passe a la version ou c'est "deprecated" ())

#if (!defined(__GNUC__) && !defined(__FUNCTION__))
#define __FUNCTION__ "???"
#endif

mais bon c'est pete couilles quand meme, pke cette macro je m'en sers pour tout ce qui est logging (et quand t'as un fichier de log qui fait plusieurs centaines de megs c'est bien de pouvoir s'y retrouver un minimum :/), et pour un profiler (c'est vachement bien ca! "???: 32.06%" et "???: 0.18%" oueee )

C'est une solution.
Mais il faut faire ça en 2 étapes: préprocesser d'abord en un fichier, puis appeler gcc (préprocesse encore une fois) ou gcc -preprocessed (ne repréprocesse pas, mais, d'après ce que je sais, attend la sortie par le préprocesseur GNU avec les numéros de ligne etc qu'il rajoute). On ne peut pas changer le préprocesseur appelé par GCC parce qu'il est interne, on peut juste empêcher qu'il soit appelé.

mmh, ok.. faudra que je regarde les specs du preproc gnu... ca serait mieux d'utiliser -preprocessed dans ce cas...

Peut-être:
#define __FUNCTION__ __FUNCTION__
tout simplement.

ah oui tiens..

sBibi :
arf ok... je savais pas que c'etait gere ca

Ça l'est toujours dans TIGCC:

2002-12-26  Kevin Kofler  <Kevin@tigcc.ticalc.org>
[...]
		* cpphash.h (mls_line, mls_col): Revert removal.
		* cpplex.c (unterminated): Likewise.
		  (parse_string): Revert removal of multi-line strings. Use "unterminated".
[...]
		* cppmain.c (scan_translation_unit): Revert removal of multi-line strings.

C'était dans le premier patchset que j'ai appliqué à GCC 3.3, en même temps que le portage du patch TIGCC.
J'avais aussi patché les versions d'avant pour supprimer le warning, après que beaucoup de personnes s'en étaient plaintes.

oue effectivement c'est un peu crade

Tu trouves? Moi, je trouve ça très pratique!

Tu trouves? Moi, je trouve ça très pratique!

bah... c'est pas deux " qui genent, et puis au moins les expaces dans la chaine sont tres clairs, et ca te fout pas en l'air ton identation
enfin je vois pas trop l'interet quoi...
(pis c'est moche tout mal idente )

sBibi
:

Kevin Kofler :
Oui, je m'en suis plaint moi aussi. Dans ce cas, je suis obligé de réverser le patch pour TIGCC, parce que TIGCCLIB en a besoin. (C'est soit ça, soit une violation des règles d'aliasing à la noix. )

ah j'avais pas ete voir tes liens dans ton premier post... oui effectivement... enfin un truc que je me demande quand meme... a part les "mainteneurs" de gcc, j'ai vu que des echos negatifs sur ces trucs la... ils s'en foutent de l'avis des gens qui utilisent leur compilo?

Visiblement, oui.

c'est pke ya rien d'autre de convenable sous nux alors ils se genent pas?

Probablement, d'où ma proposition de forker...

Et je ne peux pas non plus te garantir de faire ce patch immédiatement. Tu en as besoin dans quels délais?

non mais te prend pas la tete, la j'en ai pas _besoin_.

OK.

mais bon c'est pete couilles quand meme, pke cette macro je m'en sers pour tout ce qui est logging (et quand t'as un fichier de log qui fait plusieurs centaines de megs c'est bien de pouvoir s'y retrouver un minimum :/), et pour un profiler (c'est vachement bien ca! "???: 32.06%" et "???: 0.18%" oueee )

C'est une solution.
Mais il faut faire ça en 2 étapes: préprocesser d'abord en un fichier, puis appeler gcc (préprocesse encore une fois) ou gcc -preprocessed (ne repréprocesse pas, mais, d'après ce que je sais, attend la sortie par le préprocesseur GNU avec les numéros de ligne etc qu'il rajoute). On ne peut pas changer le préprocesseur appelé par GCC parce qu'il est interne, on peut juste empêcher qu'il soit appelé.

mmh, ok.. faudra que je regarde les specs du preproc gnu... ca serait mieux d'utiliser -preprocessed dans ce cas...

Je pense que le mieux est le trial&error: donne-lui plein de trucs à avaler et regarde ce qu'il avale... Le problème, c'est que là aussi, la syntaxe risque d'avoir changé avec GCC 3.4 et les PCHs.

sBibi
:

Tu trouves? Moi, je trouve ça très pratique!

bah... c'est pas deux " qui genent, et puis au moins les expaces dans la chaine sont tres clairs, et ca te fout pas en l'air ton identation
enfin je vois pas trop l'interet quoi...
(pis c'est moche tout mal idente )

N'oublie pas qu'il faut aussi le \n. L'intérêt des chaînes de caractères multi-lignes est d'être vraiment multi-lignes, même quand c'est compilé! C'est très pratique pour les asm (où on s'en fiche si l'indentation est inconsistente dans le fichier de sortie tant que ça compile, donc on peut indenter dans un asm).

ah ok pour les asm effectivement tu t'en fous...
quelle idee aussi d'avoir cette syntaxe a la con... c'est quand meme mieux ca merde...

__asm
{
rtdsc
mov dword ptr [clock], eax
mov dword ptr [clock + 4], edx
push eax
call truc
...
}

que je sais pas quelle immondice avec gcc et cette foutue syntaxe AT&T (ou un nom du genre)...
enfin bon oui forcement pour les bouts de code asm avec gcc tu t'en fous mais c'est le seul cas que je vois ou c'est pas crade et dur a lire (enfin c'est suffisant pour le garder). du moment que t'as une chaine ou les espaces importent ca sert vraiment a rien.

Kevin Kofler
:

Pollux
: Mon post était surtout pour répondre au post de Kevin qui disait qu'il n'aimait pas le fait que GCC deprecate des trucs (et/ou les enlève)... Pour l'exemple des multi-line string literals (dont il s'est plaint des dizaines de fois),

Pas seulement moi! Pas mal d'utilisateurs de TIGCC aussi, et des commentaires sur Slashdot aussi (à chaque newsitem parlant de GCC!).

Oué, enfin les commentaires de Slashdot, c'est pas forcément une référence en terme de pertinence

je pense que les mainteneurs de GCC avaient raison.

Et il y a pas mal d'extensions un peu "expérimentales" et bancales qui doivent être dans le même cas. Celle dont tu parles n'est pas dans ce cas-là, puisqu'elle a le mérite d'avoir une sémantique très claire...

Et les chaînes de caractères multi-lignes, elles n'ont pas une sémantique très claire???

Non, justement. Sous Win32, par exemple, un retour à la ligne doit être traduit par un \r\n ou par un \n ? Si j'utilise des routines spécifiques à Win32, je vais vouloir le premier choix, et si j'utilise des routines de la libc, ce sera plutôt le deuxième. Malheureusement, le compilo ne peut pas deviner à ma place...

Et il y a aussi les pbs de parsing que ça pose (non pas au niveau du compilo, où c'est une véritable trivialité, mais au niveau d'outils de recherche/manipulation/formattage)

* ça accroît la taille du code

dans ce cas la, ca la decroit, et de bcp si tu log massivement.
le seul truc que ca accroit, c'est eventuellement la taille de l'exe, et de facon negligeable. au final, ca fait plus chier le programmeur qu'autre chose... genial non?

Je parlais du code du compilo...

La taille et la vitesse du compilateur ne sont pas ce qu'il y a de plus important... La taille et la vitesse du code produit sont beaucoup plus importants.

Absolument. Mais les multi-line strings n'y changent strictement rien... (j'aurais même tendance à penser que ça l'affecte de manière négative, puisque si je l'utilise dans un contexte où le whitespace n'importe pas (qui est à peu près le seul contexte raisonnable où je peux l'utiliser), je vais rajouter des indentations et des newlines que je n'aurais pas eu en concaténant bêtement les chaînes).

si la feature est utile est tres utilisee (comme c'est le cas la), mieux vaut ne pas la supprimer ni la casser du tout...

vi... mais ce n'est pas le cas des multi-line string literals, par exemple.

Hein???
Cette extension était (et est toujours dans le cas de TIGCC ) utilisée dans des centaines de sources! Même le noyau Linux les utilisait dans tous les sens!

<troll> Cette feature est d'autant plus néfaste qu'elle est utilisée </troll>

Plus sérieusement, je n'ai aucune idée de l'ampleur du travail de conversion, donc je ne peux pas me prononcer : mais je soupçonne que s'ils l'ont fait, ça n'était pas si grave que ça.

Pollux :
Non, c'est

printf("truc
machin
bidule
marmotte\n");

qui est bien plus gore (pbs avec l'indentation

Il suffit de savoir qu'il ne faut pas indenter à l'intérieur de la chaîne (normal, c'est une chaîne de caractères, donc le whitespace est significatif).

Bravo, tu viens de souligner l'un des problèmes clé : c'est carrément _incompatible_ avec un formatage lisible de la source !!! (ou alors le whitespace n'importe pas dans la chaîne produite, et alors ça encourage à faire un binaire avec des caractères inutiles : je pense que cet argument te convaincra, même si personnellement j'aurais un peu tendance à m'en taper puisque le gâchis sera négligeable : le pb est surtout dans les cas où le whitespace compte)

Ca signifie aussi qu'un éditeur ne peut pas se charger automatiquement de l'indentation pour ces endroits-là sans risquer de changer la sémantique du programme : je trouve ça plutôt flippant...

et les retours à la ligne qui dépendent de la plateforme,

On utilise les retours à la ligne de la plateforme sur laquelle on travaille. C'est bon dans pratiquement tous les cas. (Surtout parce que des trucs comme printf acceptent à la fois \n et \r\n sans problèmes normalement.)

Ca m'étonnerait énormément que \r\n soit tjs accepté en remplacement de \n... Et pour un prog qui n'utilise que l'API portable, ça impliquerait qu'il se mettrait à foirer sous Win32

on ne peut pas déterminer si on est dans une chaîne sans avoir lu tout le fichier depuis le début,

Et alors? On ne peut pas non plus déterminer si on est dans un commentaire /**/ sans avoir lu tout le fichier depuis le début (ou depuis le dernier */ dans certains cas).

Oui, mais déterminer si on est dans un commentaire n'est pas forcément indispensable... Par exemple on peut avoir envie de faire grep -i '^([^"]*"(\[^\"]*\[^\"]*)*")[^"]*"(\[^\"]*\[^\"]*)*marmotte' pour avoir la liste de tous les fichiers contenant potentiellement la chaîne de caractères "marmotte", en étant certain de ne pas en rater...

J'ajouterais aussi que le statut d'un commentaire n'est pas tellement différent de celui d'une directive de compilation conditionnelle, donc à moins d'implémenter un test de satisfaisabilité d'une clause (problème NP-complet, hein ), il est impossible de savoir si un bout de code peut potentiellement être parsé par le compilateur ou s'il est mort... (et il m'arrive souvent d'utiliser des #if 0 avec du code syntaxiquement invalide, même si c'est peut-être Mal...)