Drole de main()
David Remacle
En me documentant pour un petit historique des Os d'Apple, je suis tomb�
sur une image de A/UX (l'un des premier Unix d'Apple) avec un drole de
fa�on de d�clarer main.
http://www.kernelthread.com/publications/appleoshistory/images/aux.gif
J'ai bien sur essay� de voir dans mon codeblocks si ca compile. et oui
�a compile mais tout de m�me je me pose des questions sur cette fa�on de
pr�senter main.
A bient�t.
Vivien MOREAU
> Salut,
>
> En me documentant pour un petit historique des Os d'Apple, je suis tombￜ
> sur une image de A/UX (l'un des premier Unix d'Apple) avec un drole de
> faï¿œon de dï¿œclarer main.
C'est du K&R C, celui d'avant la standardisation de 1989 par
l'ANSI, ￜ priori.
--
Vivien MOREAU / vpm
Samuel Devulder
C'est pas une drole de fa�on de pr�senter. C'est la syntaxe d'origine
(avant l'ansi), celle du K&R. En fait ca s'applique � toutes les
fonctions et pas uniquement au main() (le mains n'a rien de sp�ciale:
c'est une fonctionne comme une autre).
A la base cela revient � d�clarer le type des arguments avant le bloc
contenant le code..
Et si on d�clare rien alors? Et bien dans ce cas le C consid�re que ce
sont des entiers, ce qui fait que:
int
f(a)
{
return a>=0?1:a*f(a-1);
}
est valide. Autre exemple: (code de l'auteur de qemu, tcc.. un vrai
malade :) ) http://www.de.ioccc.org/2000/bellard.c
Cette construction est souvent utilis�e dans les exercices/comp�titions
de code C "illisibles, rikikis mais costauds" (http://www.ioccc.org/):
on �vite de d�clarer des entiers en les passant dans la d�claration des
args de la fonction et on gagne quelques caract�res pr�cieux dans
l'exercice, en plus de perdre celui qui tente de lire le code sans en
�tre l'auteur.
sam (pour se faire tr�s peur: http://www.de.ioccc.org/years.html)
Wykaaa
C'est comme cela qu'�taient d�finis les param�tres des fonctions (pas
seulement de main) avant le C ANSI quand les prototypes de fonctions
n'�taient pas encore dans le langage. Les param�tres de fonction
devaient �tre d�finis entre l'en-t�te de fonction et son bloc principal.
On ne pouvait pas faire une d�claration de fonction (prototype)
du genre :
f (int i);
JKB
Drole de main(),
David Remacle ?crivait dans fr.comp.lang.c :
> Salut,
Bonsoir,
> En me documentant pour un petit historique des Os d'Apple, je suis tombé
> sur une image de A/UX (l'un des premier Unix d'Apple) avec un drole de
> façon de déclarer main.
>
> http://www.kernelthread.com/publications/appleoshistory/images/aux.gif
>
> J'ai bien sur essayé de voir dans mon codeblocks si ca compile. et oui
> ça compile mais tout de même je me pose des questions sur cette façon de
> présenter main.
C'est à ça qu'on voit si on a affaire à un dinosaure avec des
écailles ou à un petit jeune ;-)
C'est du C K&R (comprendre pré ANSI) avec les déclarations de
fonction telles que Dieu les a crées (euh, pardon, ça, c'est pour
les boucles en TeX, mais l'idée est la même ;-) ).
Cordialement,
JKB
--
Le cerveau, c'est un véritable scandale écologique. Il représente 2% de notre
masse corporelle, mais disperse à lui seul 25% de l'énergie que nous
consommons tous les jours.
Marc Espie
JKB <wilhelm-siegfried.k...@chezmoi.com> wrote:
>Le 18-12-2009, ? propos de
>Drole de main(),
> David Remacle ?crivait dans fr.comp.lang.c :
>> Salut,
>
> Bonsoir,
>
>> En me documentant pour un petit historique des Os d'Apple, je suis tombé
>> sur une image de A/UX (l'un des premier Unix d'Apple) avec un drole de
>> façon de déclarer main.
>>
>> http://www.kernelthread.com/publications/appleoshistory/images/aux.gif
>>
>> J'ai bien sur essayé de voir dans mon codeblocks si ca compile. et oui
>> ça compile mais tout de même je me pose des questions sur cette façon de
>> présenter main.
>
> C'est à ça qu'on voit si on a affaire à un dinosaure avec des
> écailles ou à un petit jeune ;-)
>
> C'est du C K&R (comprendre pré ANSI) avec les déclarations de
> fonction telles que Dieu les a crées (euh, pardon, ça, c'est pour
> les boucles en TeX, mais l'idée est la même ;-) ).
>
> Cordialement,
>
> JKB
Juste pour completer, les declarations de fonction en question sont encore
valides en C ISO, que ce soit 89 ou 99, precisement pour comptabilite avec
le vieux code. Elles commencent a etre fortement depreciees (ca se traduit
comment deprecated) avec une nette envie du comite de les virer.
Le "passage au C ISO" n'est aucunement automatique, il ne suffit PAS de
prendre la declaration ancienne mode et de rajouter les types. Avec des
declarations K&R, on n'a pas de prototypes, et les conventions d'appels
sont differentes. Par exemples, les char sont etendues en int pour l'appel.
Ce qui fait que la definition suivante:
f(a)
char a;
{
/* faire quelque chose avec a */
}
se traduira le plus souvent en
void /* pas de type de retour, c'est int formellement, mais on s'en
* servait pour les fonctions ne renvoyant rien d'utile avant
* l'existence de void */
f(int a)
{
char b = a;
/* faire quelque chose avec b */
}
oui, c'est sacrement tordu, et ca a piege plus d'un programmeur confirme...
Jean-marc
> In article <slrnhinauc.9...@rayleigh.systella.fr>,
> JKB <wilhelm-siegfried.k...@chezmoi.com> wrote:
> Elles commencent a etre fortement
> depreciees (ca se traduit comment deprecated) ...
"D�pr�ci�es" est un faux-ami ici, malheureusement.
"Obsol�te" ne convient pas : un poil trop strict.
"d'usage d�courag�" n'est pas mal et est exact, � d�faut
d'�tre joli.
Finalement, "caduc" me semble le mieux et c'est ce que j'emploierais
si je devais traduire.
--
Jean-marc
JKB
Marc Espie ?crivait dans fr.comp.lang.c :
Mais c'est sacrément logique. C'est même à cause de ce genre de
trucs que je milite depuis très longtemps pour l'abrogation du K&R
dans sa première mouture !
Samuel Devulder
> f(a)
> char a;
> {
> /* faire quelque chose avec a */
> }
>
> se traduira le plus souvent en
>
> void /* pas de type de retour, c'est int formellement, mais on s'en
> * servait pour les fonctions ne renvoyant rien d'utile avant
> * l'existence de void */
> f(int a)
> {
> char b = a;
> /* faire quelque chose avec b */
> }
>
>
> oui, c'est sacrement tordu, et ca a piege plus d'un programmeur confirme...
En fait j'ai du mal � voir le probl�me: les param�tres sont align�s sur
la pile sur la taille d'un int. C'est pas tellement diff�rent des ABI
actuelles ou les params sont pass�s dans des registres.
Peux tu pr�ciser en quoi c'est pi�geux? J'avoue ne pas suivre ici. Tu
veux dire que les conventions ABI sont diff�rentes entre K&R et ANSI?
sam.
Marc Espie
Samuel Devulder <samuel-do...@geensys.com> wrote:
>En fait j'ai du mal � voir le probl�me: les param�tres sont align�s sur
>la pile sur la taille d'un int. C'est pas tellement diff�rent des ABI
>actuelles ou les params sont pass�s dans des registres.
Certains parametres dans certaines conditions. Pas toutes les ABI.
>Peux tu pr�ciser en quoi c'est pi�geux? J'avoue ne pas suivre ici. Tu
>veux dire que les conventions ABI sont diff�rentes entre K&R et ANSI?
Ben oui, les conventions sont differentes. En particulier, le compilo, s'il
a un prototype, peut optimiser les choses. Si tu passes plein de char a une
fonction, avec un prototype, le compilo peut tres bien te les coller sur la
pile serres les uns contre les autres, alors qu'avec l'ancienne declaration
il sera force de les etendre en int.
Si tu ne vois pas le probleme, c'est juste que tu n'as pas regarde assez loin.
Je ne te parle pas d'une fonction, mais d'un programme entier, censement
portable, ou tu vas convertir plusieurs centaines de fonctions d'un monde
a l'autre. Si tu le fais a la main, tu as de fortes chances de te planter sur
au moins quelques-unes. Et comme Murphy est toujours avec nous, tu es a peu
pres certain que ca va marcher sur ta machine courante, mais pas sur une
autre. Cas vecu: i386, amd64, ppc. Et paf le ppc.
Samuel Devulder
> In article <4b2c0029$0$14550$426a...@news.free.fr>,
> Samuel Devulder <samuel-do...@geensys.com> wrote:
>> Peux tu pr�ciser en quoi c'est pi�geux? J'avoue ne pas suivre ici. Tu
>> veux dire que les conventions ABI sont diff�rentes entre K&R et ANSI?
>
> Ben oui, les conventions sont differentes. En particulier, le compilo, s'il
ok.
> a un prototype, peut optimiser les choses. Si tu passes plein de char a une
> fonction, avec un prototype, le compilo peut tres bien te les coller sur la
> pile serres les uns contre les autres, alors qu'avec l'ancienne declaration
> il sera force de les etendre en int.
>
> Si tu ne vois pas le probleme, c'est juste que tu n'as pas regarde assez loin.
De ce que tu explique, je comprends que c'est consistant, et c'est pour
ca que je ne vois pas de probl�mes en mode 100% K&R.
> Je ne te parle pas d'une fonction, mais d'un programme entier, censement
> portable, ou tu vas convertir plusieurs centaines de fonctions d'un monde
> a l'autre. Si tu le fais a la main, tu as de fortes chances de te planter sur
> au moins quelques-unes.
Dison qu'on va se planter en loupant la bonne d�claration du proto
quelque part. Mais il y a des flags du compilo pour raler dans ces
circonstances.
C'est pas pire que si dans deux fichiers C on appellait la m�me
fonction, mais avec des prototype diff�rents.
f1.c:
extern double f(double a, double b);
...f(1.2, 3.4);...
f2.c:
extern char f(char a, char b);
...f('a', 'b');
f3.c:
int f(int a, int b) {return a*b;}
Comme la signature de la fonction n'intervient pas dans l'ABI, et que le
namespace est global, le linker va appeller f avec la mauvaise structure
de pile ou registre.. et bingo.. crash! C'est d'ailleurs pour cela qu'il
veut mieux mettre l'extern dans un .h unique et s�par� de sorte � ce que
chaque fonction ait un et un seul prototype.
Et comme Murphy est toujours avec nous, tu es a peu
> pres certain que ca va marcher sur ta machine courante, mais pas sur une
> autre. Cas vecu: i386, amd64, ppc. Et paf le ppc.
Oui si mixer K&R et ANSI c'est pas bon.
sam (merci pour les explications).
JKB
Re: Drole de main(),
Marc Espie ?crivait dans fr.comp.lang.c :
> Samuel Devulder <samuel-do...@geensys.com> wrote:
>>la pile sur la taille d'un int. C'est pas tellement différent des ABI
>>actuelles ou les params sont passés dans des registres.
>
> Certains parametres dans certaines conditions. Pas toutes les ABI.
>
>>veux dire que les conventions ABI sont différentes entre K&R et ANSI?
>
> Ben oui, les conventions sont differentes. En particulier, le compilo, s'il
> a un prototype, peut optimiser les choses. Si tu passes plein de char a une
> fonction, avec un prototype, le compilo peut tres bien te les coller sur la
> pile serres les uns contre les autres, alors qu'avec l'ancienne declaration
> il sera force de les etendre en int.
>
> Si tu ne vois pas le probleme, c'est juste que tu n'as pas regarde assez loin.
> Je ne te parle pas d'une fonction, mais d'un programme entier, censement
> portable, ou tu vas convertir plusieurs centaines de fonctions d'un monde
> a l'autre. Si tu le fais a la main, tu as de fortes chances de te planter sur
> au moins quelques-unes. Et comme Murphy est toujours avec nous, tu es a peu
> pres certain que ca va marcher sur ta machine courante, mais pas sur une
> autre. Cas vecu: i386, amd64, ppc. Et paf le ppc.
Je rajouterai : "et paf le sparc !"
Il suffit de regarder mono, seamonkey, enfin tous ces trucs codés
sur i386/amd64 qui buserrorent à donf sur ces problèmes ;-)
Marc Espie
JKB <wilhelm-siegfried.k...@chezmoi.com> wrote:
>> autre. Cas vecu: i386, amd64, ppc. Et paf le ppc.
>
> Je rajouterai : "et paf le sparc !"
>
> Il suffit de regarder mono, seamonkey, enfin tous ces trucs codés
> sur i386/amd64 qui buserrorent à donf sur ces problèmes ;-)
Oui, non. Ne melange pas tout.
Les problemes de segfault des sparc proviennent le plus souvent d'un gros
melange entre entiers et pointeurs. Ils sont rarement, voire jamais,
lies a des vieilles definitions de fonctions K&R.
Cite-moi un exemple ou c'est le cas... mono et seamonkey sont bien trop
recents pour avoir des proto K&R.
Dans les vieux classiques a corriger, il y a tous les callbacks de la xlib
qui prennent des pointeurs, et des gens tres cradouilles qui ont abuse cette
interface pour y mettre des entiers (exemple: ghostview). Ou alors les
gens qui lisent des trucs directement depuis un fichier vers une structure,
et qui essaient de caster directement un bout de buffer a un offset arbitraire
vers un pointeur (exemple: unrar).
Non, je n'ai pas du tout choisi le cas ppc au hasard. C'est bien plus sournois.
Autant les bus error du sparc sont simples a diagnostiquer (et generalement
chiantes a corriger), autant les problemes de "signedness" du char, qui est
different sur ppc d'a peu pres toutes les autres architectures (sur les ABI
courantes, hein, puisque c'est un truc qui peut se changer avec des flags du
compilo) produit des problemes subtils et chiants a diagnostiquer lors de
ce type de conversion.
Marc Espie
Samuel Devulder <samuel-do...@geensys.com> wrote:
>De ce que tu explique, je comprends que c'est consistant, et c'est pour
>ca que je ne vois pas de probl�mes en mode 100% K&R.
>
>> Je ne te parle pas d'une fonction, mais d'un programme entier, censement
>> portable, ou tu vas convertir plusieurs centaines de fonctions d'un monde
>> a l'autre. Si tu le fais a la main, tu as de fortes chances de te planter sur
>> au moins quelques-unes.
>
>Dison qu'on va se planter en loupant la bonne d�claration du proto
>quelque part. Mais il y a des flags du compilo pour raler dans ces
>circonstances.
Non, tu n'as rien compris a ce qu'on fait.
Il s'agit generalement de moderniser du code, ce qui implique de changer
la definition de fonction pour se debarrasser du style K&R, et de rajouter
les prototypes qui vont bien.
Il n'y a pas de flag du compilo qui peut te donner les warnings qui vont
bien. Tu peux eventuellement proceder par etape (rajouter le prototype
d'abord, puis changer la definition), mais ca n'est pas intuitif quand meme,
et le compilateur ne t'aidera pas. L'exemple precis que je citais (passage
par un char) ne genere aucun warning meme si tu fais les choses de travers.
Pour:
f(a)
char a;
{
}
Le prototype correspondant est
extern void f(int);
et il faut que tu utilises celui-ci pour garder l'ABI (la, le compilo avertit
si tu te plantes).
Quand apres tu convertis la definition de fonction, tu ne peux pas te
contenter de:
void
f(int a)
{
}
ca depend de ce que tu fais dans la fonction avec a. Et le compilo n'avertira
pas, parce que int et char, c'est generalement interchangeable a l'interieur
de ton code, sauf que ca n'a pas la meme semantique en ce qui concerne les
extensions de signes et autres trucs rigolo.
Stricto sensu, il faut ecrire un truc du genre:
void(int a_)
{
char a = a_;
...
}
et verifier a la loupe si tu peux te debarrasser du a_...
Samuel Devulder
> Non, tu n'as rien compris a ce qu'on fait.
Oui je pense.. car ya un truc qui m'�chappe.
> Pour:
>
> f(a)
> char a;
> {
> }
>
> Le prototype correspondant est
> extern void f(int);
>
> et il faut que tu utilises celui-ci pour garder l'ABI (la, le compilo avertit
> si tu te plantes).
Question: pourquoi dans le cadre d'une r�-�criture ou un portage
tient-on � garder la compatibilit� avec l'ancienne ABI? Si on change
tous les sources d'un coup il n'y a pas de pbs. Tout sera coh�rent et
compatible. Je vois peu de risque la dedans.
Peut-�tre que tu me parles de la situation transitoire avec un mix K&R
et ANSI.. l� oui mais bon c'est transitoire. Si le vieux code link� avec
la nouvelle libmachin.a plante pour des raisons de convention de passage
de params sur la pile, il faut mettre � jour ce vieux code et pas
essayer de l'hybrider avec des trucs modernes.
Enfin bon peut �tre que si tu convertis un bout et tu finis par devoir
convertir beaucoup plus que le source d'origine. C'est sur c'est du
boulot.. mais rien n'est gratuit/magique.
Mais quoi qu'il en soit ca n'est pas la syntaxe ou l'ABI K&R, mais le
mixe de deux conventions diff�rentes et pas forc�ment compatible qui est
risqu�.
> Stricto sensu, il faut ecrire un truc du genre:
> void(int a_)
> {
> char a = a_;
> ...
> }
>
> et verifier a la loupe si tu peux te debarrasser du a_...
Personne n'a eu l'id�e de manipuler les AST (arbre syntaxique) du C pour
faire cela automatiquement? La transfo ne me semble pas super complexe
quand on a un bon AST du C (L'AST de Eclipse/CDT me semble utile pour
cela).
sam.
Jean-Marc Bourguet
> Marc Espie a �crit :
>
>> Non, tu n'as rien compris a ce qu'on fait.
>
> Oui je pense.. car ya un truc qui m'�chappe.
>
>> Pour:
>>
>> f(a)
>> char a;
>> {
>> }
>>
>> Le prototype correspondant est
>> extern void f(int);
>>
>> et il faut que tu utilises celui-ci pour garder l'ABI (la, le compilo avertit
>> si tu te plantes).
>
> Question: pourquoi dans le cadre d'une r�-�criture ou un portage tient-on �
> garder la compatibilit� avec l'ancienne ABI?
Pour n'avoir pas � changer toutes les sources d'un coup. (Parce que c'est
un gros boulot qu'on r�partit sur une p�riode longue plut�t que d'essayer
de vendre un "on arr�te tout pendant 2 semaines le temps de faire �a",
parce qu'on veut pouvoir tester des �tapes interm�diaires pour trouver plus
facilement un changement qui poserait probl�me -- ce probl�me pouvant �tre
existant mais maintenant demasqu� --, parce qu'il y a des clients internes
ou externes qu'on ne peut pas forcer � changer avec le m�me planning).
> Personne n'a eu l'id�e de manipuler les AST (arbre syntaxique) du C pour
> faire cela automatiquement? La transfo ne me semble pas super complexe
> quand on a un bon AST du C (L'AST de Eclipse/CDT me semble utile pour
> cela).
On parle d'un boulot qui s'est fait quand m�me pour l'essentiel au d�but
des ann�es 90. (M�me gcc a abandonn�e l'id�e d'�tre compilable en K&R et
essaie plut�t de se rendre compilable en C++).
A+
--
Jean-Marc
FAQ de fclc: http://www.levenez.com/lang/c/faq
Site de usenet-fr: http://www.usenet-fr.news.eu.org
Samuel Devulder
> Samuel Devulder <samuel-do...@geensys.com> writes:
>
>> Question: pourquoi dans le cadre d'une r�-�criture ou un portage tient-on �
>> garder la compatibilit� avec l'ancienne ABI?
>
> Pour n'avoir pas � changer toutes les sources d'un coup.
Oui ok.. On veut nettoyer un code, bref on tire un tout petit bout de
fil qui depasse, au au final on se rend compte qu'on tire toute la
pelotte derri�re. Fallait pas commencer en fait :-)
> On parle d'un boulot qui s'est fait quand m�me pour l'essentiel au d�but
> des ann�es 90. (M�me gcc a abandonn�e l'id�e d'�tre compilable en K&R et
> essaie plut�t de se rendre compilable en C++).
Oui ok.. mais les arbres syntaxiques existent depuis longtemps et ma foi
l'id�e d'automatiser les op�rations r�p�titives et dangereuses si faites
par un humain aurait pu �merger. Mais il est aussi probable que la
conversion de vieux source n'attire pas les foules. On pr�f�re souvent
r�-�crire "en mieux" le truc d'avant. Mais bon souvent le mieux est
l'ennemi du bien.
sam.
Wykaaa
[snip]
>
> C'est pas pire que si dans deux fichiers C on appellait la m�me
> fonction, mais avec des prototype diff�rents.
>
> f1.c:
> extern double f(double a, double b);
> ...f(1.2, 3.4);...
>
> f2.c:
> extern char f(char a, char b);
> ...f('a', 'b');
>
> f3.c:
> int f(int a, int b) {return a*b;}
>
> Comme la signature de la fonction n'intervient pas dans l'ABI, et que le
> namespace est global, le linker va appeller f avec la mauvaise structure
> de pile ou registre.. et bingo.. crash! C'est d'ailleurs pour cela qu'il
> veut mieux mettre l'extern dans un .h unique et s�par� de sorte � ce que
> chaque fonction ait un et un seul prototype.
Parce que certains font autrement ?
Ils ont �t� mal form�s alors...
Wykaaa
> Marc Espie a �crit :
>
>> Non, tu n'as rien compris a ce qu'on fait.
>
> Oui je pense.. car ya un truc qui m'�chappe.
>
>> Pour:
>>
>> f(a)
>> char a;
>> {
>> }
>>
>> Le prototype correspondant est
>> extern void f(int);
>>
>> et il faut que tu utilises celui-ci pour garder l'ABI (la, le compilo
>> avertit
>> si tu te plantes).
>
> Question: pourquoi dans le cadre d'une r�-�criture ou un portage
> tient-on � garder la compatibilit� avec l'ancienne ABI? Si on change
> tous les sources d'un coup il n'y a pas de pbs. Tout sera coh�rent et
> compatible. Je vois peu de risque la dedans.
>
> Peut-�tre que tu me parles de la situation transitoire avec un mix K&R
> et ANSI.. l� oui mais bon c'est transitoire. Si le vieux code link� avec
> la nouvelle libmachin.a plante pour des raisons de convention de passage
> de params sur la pile, il faut mettre � jour ce vieux code et pas
> essayer de l'hybrider avec des trucs modernes.
Tu n'as pas l'air d'avoir manipul� des applications C de plusieurs
centaines de milliers de lignes toi.
>
> Enfin bon peut �tre que si tu convertis un bout et tu finis par devoir
> convertir beaucoup plus que le source d'origine. C'est sur c'est du
> boulot.. mais rien n'est gratuit/magique.
Et sur de grosses applications, �a va prendre plusieurs mois, voire
plusieurs ann�es....
>
> Mais quoi qu'il en soit ca n'est pas la syntaxe ou l'ABI K&R, mais le
> mixe de deux conventions diff�rentes et pas forc�ment compatible qui est
> risqu�.
>
>> Stricto sensu, il faut ecrire un truc du genre:
>> void(int a_)
>> {
>> char a = a_;
>> ...
>> }
>>
>> et verifier a la loupe si tu peux te debarrasser du a_...
>
> Personne n'a eu l'id�e de manipuler les AST (arbre syntaxique) du C pour
> faire cela automatiquement? La transfo ne me semble pas super complexe
> quand on a un bon AST du C (L'AST de Eclipse/CDT me semble utile pour
> cela).
Il est s�r que si l'on veut faire "tout d'un coup" sur une tr�s grosse
application, il va falloir automatiser.
Samuel Devulder
>> Peut-�tre que tu me parles de la situation transitoire avec un mix K&R
>> et ANSI.. l� oui mais bon c'est transitoire. Si le vieux code link�
>> avec la nouvelle libmachin.a plante pour des raisons de convention de
>> passage de params sur la pile, il faut mettre � jour ce vieux code et
>> pas essayer de l'hybrider avec des trucs modernes.
>
> Tu n'as pas l'air d'avoir manipul� des applications C de plusieurs
> centaines de milliers de lignes toi.
Ne pr�sume pas plus que tu ne peux STP. Tu ne me connais pas. Compiler
et maintenir 100 000 lignes c'est rien du tout, mais rien de rien. Tiens
la semaine derni�re je faisais de la compilation de plus de 60 millions
de lignes de C (et c'est un *PETIT* projet.) Tu sais que franchement tu
commences � etre ch*ant avec tes attaques ad hominem. Retournes sur ton
compilo C super optimis� (ton baton de marechal si je comprends) et
laisse les gens discuter tranquillement. Merci.
>>
>> Enfin bon peut �tre que si tu convertis un bout et tu finis par devoir
>> convertir beaucoup plus que le source d'origine. C'est sur c'est du
>> boulot.. mais rien n'est gratuit/magique.
>
> Et sur de grosses applications, �a va prendre plusieurs mois, voire
> plusieurs ann�es....
A ce compte l�, on peut se demander s'il ne vaut pas mieux refaire. Si
ca prend plusieurs ann�es il y a fort � parier que quand la conversion
sera finie, quelqu'un aura d�j� recod� "from scratch" le truc ou que le
produit aura �t� remplac� par quelque chose de plus moderne.
sam.
Samuel Devulder
> Parce que certains font autrement ?
> Ils ont �t� mal form�s alors...
Je sais pas. Ca se rencontre, c'est tout. C'est probablement pas un
probl�me de formation, mais un probl�me de projet un peu vieux avec des
incoh�rences introduite par de trop nombreux intervenants. Un peu comme
ce thread peut-�tre.
sam (peut-etre....)
Marc Espie
Non, il n'y a guere que toi qui est confus. Je pense que Wykaaa et moi, on
est parfaitement en phase sur le coup.
(nota bene: la compilation separee, c'est un truc que j'explique en detail
dans les 10 premieres heures de cours en C)
Samuel Devulder
> Non, il n'y a guere que toi qui est confus.
Je pense �tre consistant et clair.
Je pense que Wykaaa et moi, on
> est parfaitement en phase sur le coup.
Vous �tes en phases, .. mais du coup vous vous comprenez � demi-mots et
demi-exemples et perdez les autres. Enfin c'est mon avis. Du reste
personne (sauf Jean-Marc) n'a clairement r�pondu � ma question initiale
(qui n'�tait pas une attaque ou une remise en cause de ton travail, si
c'est que tu as compris)
Je me recite, d�sol� Marc, mais franchement j'attends une r�ponse et pas
des digressions hors sujets, voir sur des attaques ad hominem.
<<Question: pourquoi dans le cadre d'une r�-�criture ou un
portage tient-on � garder la compatibilit� avec l'ancienne ABI?
Si on change tous les sources d'un coup il n'y a pas de pbs.
Tout sera coh�rent et compatible. Je vois peu de risque la
dedans.>>
Tu le sais, on se connait sur usenet depuis pas mal de temps (combien?
14-15ans). On a travaill� tous les deux � diff�rents portages de trucs
"gnu" ou pas sur de nombreuses plateformes et mes question sont plut�t
l�gitimes. Perso j'ai pas eu de soucis quand j'ai eu � r�utiliser et
convertir du K&R vers de l'ANSI dans le pass�.
Un probl�me apparait en cours de route quand le travail de conversion
n'est que partiel et qu'on se trouve � avoir des bouts de codes en K&R
et d'autres en ANSI. D'o� la 2eme question concernant l'automatisation
du processus de conversion pour pouvoir le mener � bout sans laisser de
"trous" dans l'ouvrage.
Franchement tu trouves cela confus? moi pas.
sam.
Wykaaa
> Wykaaa a �crit :
>
>>> Peut-�tre que tu me parles de la situation transitoire avec un mix
>>> K&R et ANSI.. l� oui mais bon c'est transitoire. Si le vieux code
>>> link� avec la nouvelle libmachin.a plante pour des raisons de
>>> convention de passage de params sur la pile, il faut mettre � jour ce
>>> vieux code et pas essayer de l'hybrider avec des trucs modernes.
>>
>> Tu n'as pas l'air d'avoir manipul� des applications C de plusieurs
>> centaines de milliers de lignes toi.
>
> Ne pr�sume pas plus que tu ne peux STP. Tu ne me connais pas. Compiler
> et maintenir 100 000 lignes c'est rien du tout, mais rien de rien. Tiens
> la semaine derni�re je faisais de la compilation de plus de 60 millions
> de lignes de C (et c'est un *PETIT* projet.) Tu sais que franchement tu
> commences � etre ch*ant avec tes attaques ad hominem. Retournes sur ton
> compilo C super optimis� (ton baton de marechal si je comprends) et
> laisse les gens discuter tranquillement. Merci.
60 millions de lignes, une seule application ?
Je ne connais qu'un projet qui d�passe cette taille c'est l'ISS (80
millions de lignes) mais en comptant tout : les simulateurs, les lignes
de tests, etc.
Le compilo C n'�tait pas mon b�ton de mar�chal du tout, c'�tait il y a
25 ans et depuis j'ai fait bien d'autres choses avant d'arr�ter l'ann�e
derni�re.
>
>>>
>>> Enfin bon peut �tre que si tu convertis un bout et tu finis par
>>> devoir convertir beaucoup plus que le source d'origine. C'est sur
>>> c'est du boulot.. mais rien n'est gratuit/magique.
>>
>> Et sur de grosses applications, �a va prendre plusieurs mois, voire
>> plusieurs ann�es....
>
> A ce compte l�, on peut se demander s'il ne vaut pas mieux refaire. Si
> ca prend plusieurs ann�es il y a fort � parier que quand la conversion
> sera finie, quelqu'un aura d�j� recod� "from scratch" le truc ou que le
> produit aura �t� remplac� par quelque chose de plus moderne.
En quarante ans d'informatique je n'ai JAMAIS vu une grosse application
enti�rement recod�e. J'ai toujours vu des rafistolages pour la faire
durer le plus longtemps possible, h�las.
Samuel Devulder
> 60 millions de lignes, une seule application ?
60 Milions de lignes de code trait�es par le compilo pour un seul
fichier ELF. Oui et c'est normal et m�me assez courant. Ca tourne sur
des trucs tout nus sans OS ni rien � la base, donc dans le truc que tu
compile tu te retrouves � avoir les couches de bas niveau, l'OS et
l'applicatif. 60Milions, c'est approximativement le nombre de lignes
trait�es par CodeWarrior (avec Greenhills ca serait pareil du reste..
C'est pas les 2/3 #ifdef qui changent grand chose sur un nombre aussi
grand).
> Je ne connais qu'un projet qui d�passe cette taille c'est l'ISS (80
> millions de lignes) mais en comptant tout : les simulateurs, les lignes
> de tests, etc.
Il faut croire qu'il y a de l'inflation en tout. Quand tu penses que sur
ces trucs embarqu�s on met des OS de plus en plus riches avec des piles
de communication en tout genres... Ca fait des lignes tout cela.
sam.
Jean-Marc Bourguet
> Un probl�me apparait en cours de route quand le travail de conversion
> n'est que partiel et qu'on se trouve � avoir des bouts de codes en K&R et
> d'autres en ANSI. D'o� la 2eme question concernant l'automatisation du
> processus de conversion pour pouvoir le mener � bout sans laisser de
> "trous" dans l'ouvrage.
Je me suis rappel� qu'il y avait au moins,
http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Running-Protoize.html
mais je n'ai pas d'exp�rience avec (quand c'�tait pertinent, je faisais
autre chose).
Wykaaa
> Wykaaa a �crit :
>
>> 60 millions de lignes, une seule application ?
>
> 60 Milions de lignes de code trait�es par le compilo pour un seul
> fichier ELF. Oui et c'est normal et m�me assez courant. Ca tourne sur
> des trucs tout nus sans OS ni rien � la base, donc dans le truc que tu
> compile tu te retrouves � avoir les couches de bas niveau, l'OS et
> l'applicatif. 60Milions, c'est approximativement le nombre de lignes
> trait�es par CodeWarrior (avec Greenhills ca serait pareil du reste..
> C'est pas les 2/3 #ifdef qui changent grand chose sur un nombre aussi
> grand).
OK. Je n'avais pas pens� � ce genre d'environnement.
>
>> Je ne connais qu'un projet qui d�passe cette taille c'est l'ISS (80
>> millions de lignes) mais en comptant tout : les simulateurs, les
>> lignes de tests, etc.
>
> Il faut croire qu'il y a de l'inflation en tout. Quand tu penses que sur
> ces trucs embarqu�s on met des OS de plus en plus riches avec des piles
> de communication en tout genres... Ca fait des lignes tout cela.
>
> sam.
Soit-disant confort, confort, confort !
Antoine Leca
> De ce que tu explique, je comprends que c'est consistant, et c'est pour
> ca que je ne vois pas de probl�mes en mode 100% K&R.
Le probl�me n'est pas le mode 100% K&R (qui n'int�resse quasiment plus
personne aujourd'hui), mais le mode mixte.
Avec en plus l'�vidence � grav�e dans le marbre en trois exemplaires �
que ce mode mixte est amen� � dispara�tre � terme, ce qui fait que les
efforts consentis sont toujours minimes (puisque inutiles).
> C'est pas pire que si dans deux fichiers C on appellait la m�me
> fonction, mais avec des prototype diff�rents.
Qui, soit dit en passant, �tait LE grand probl�me du mode 100% K&R, au
point que le mode Ansi a pu supplant� le mode K&R sur ce seul argument.
Dit autrement : le standard Ansi a d'autres qualit�s, mais j'ai la
sensation que s'il n'y avait pas eu cet avantage tr�s net au niveau des
d�clarations de fonction, la transition n'aurait pas �t� aussi rapide,
cf. la situation de la norme C99 qui ne semble pas impos�e partout.
> Question: pourquoi dans le cadre d'une r�-�criture ou un portage
> tient-on � garder la compatibilit� avec l'ancienne ABI?
Parce que tu n'as pas les sources sous la main ?
Prenons le cas d'une biblioth�que utilis�e par X mais d�velopp�e par Y.
Si tu es X, tu vas d'abord �crire des prototypes � compatibles K&R �
(comme d�crit par Marc), pour pouvoir lier avec la biblioth�que fournie
(sous forme de binaire).
Dans le m�me temps, les joyeux d�veloppeurs de Y font �voluer leur
biblioth�que, adoptent le mode Ansi... ce qui pour eux signifie rajouter
des prototypes correspondants, et oui cela casse la compatibilit�
binaire, donc quand ils livrent la nouvelle version de la biblioth�que
en version alpha � leur /client/ X, cela l�ve une temp�te de
protestation... les positions deviennent outr�es (il suffit d'avoir lu
un rapport d'anomalie dans un processus de recette pour savoir de quoi
je parle), le management s'en m�le, et parfois (pas toujours) c'est la
position de X qui gagne, au moins dans un premier temps... et donc Y est
oblig� de r�viser sa mouture et de garder l'ancienne ABI.
> Si on change tous les sources d'un coup il n'y a pas de pbs.
Si tu as tous les sources, tu n'as pas de raison d'avoir des probl�mes
d'ABI. Le concept m�me d'ABI est justement de ne pas devoir d�pendre des
sources pour �tre interop�rable.
Antoine
Marc Espie
Antoine Leca <ro...@localhost.invalid> wrote:
>Qui, soit dit en passant, �tait LE grand probl�me du mode 100% K&R, au
>point que le mode Ansi a pu supplant� le mode K&R sur ce seul argument.
>Dit autrement : le standard Ansi a d'autres qualit�s, mais j'ai la
>sensation que s'il n'y avait pas eu cet avantage tr�s net au niveau des
>d�clarations de fonction, la transition n'aurait pas �t� aussi rapide,
>cf. la situation de la norme C99 qui ne semble pas impos�e partout.
Pour la norme C99, les changements sont quand meme minimes par rapport
a la norme C89. Le fait d'etre C99 ne va pas changer enormement les programmes
qui compilent/ne compilent pas. Les tres bonnes idees de C99 ont ete adoptees
tres vite (temoin les nouveaux fichiers d'entetes stdint.h et consorts qui
resolvaient un vieux probleme bien connu).
Pour les autres idees, il y a une
part de gros souci sur certain compilo bien connu. Les gens de gcc pratiquent
l'obsolescence rapide. si tu essaies de travailler avec eux, c'est tres dur,
parce qu'ils ont toute leur energie sur la version courante, avec rarement
des backports. Or, la plupart des vieilles architectures ou des vieux OS ne
fonctionnent pas avec du gcc recent. Et en plus, du gcc recent prend des
jours, voire des semaines a compiler sur une sparc ou un amiga...
Ca a un cote un peu decourageant. Tu corriges un bug, tu envoies un patch,
on te demande de le porter sur une version recente. Tu essaies de compiler,
la version recente ne compile pas. Il faut dire qu'elle est generalement
cassee les 3/4 du temps sur autre chose qu'un linux-i386. Lorsqu'enfin tu
en as une qui marche, c'est une version stable. Tu reecris ton patch,
qui a evidemment completement change entre temps, parce que toute
l'infrastructure de ton compilo a bouge, et tu te refais envoye sur les roses,
parce que la version stable est obsolete, cote developpement, ils sont deja
six mois plus loin, avec d'autres modifications... et une fois de plus, une
version de dev qui ne compile pas chez toi. Il faut une patience de jesuite
pour travailler avec eux dans ces conditions. Moi j'avoue, j'ai abandonne.
La seule facon aujourd'hui de participer au developpement de GCC pour des
choses non triviales, c'est d'etre a plein temps dessus, et personne ne va
te payer a plein temps pour reparer des trucs sur une sparc.
Par exemple, en C99, les definitions de variable n'importe ou. Ca a necessite
des changements assez profonds dans le parser. Ces changements sont donc
presents a partir d'une certaine version de gcc. Si tu es contraint d'utiliser
une version plus ancienne de gcc---ce qui est le cas sur OpenBSD pour quelques
rares archis---ben tu n'as pas le droit d'utiliser cet idiome dans du code
portable. (les modifs en question sont suffisamment opaques et etalees sur
suffisamment de commits pour que ca soit impossible a retrouver).
Et c'est comme ca pour plein de nouveautes de C99: aucun souci sur de
l'amd64/i386. Et d'enormes problemes si tu veux etre portable ailleurs...
Antoine Leca
> Les gens de gcc pratiquent l'obsolescence rapide.
> Tu reecris ton patch,
> qui a evidemment completement change entre temps, parce que toute
> l'infrastructure de ton compilo a bouge, et tu te refais envoye sur les roses,
> parce que la version stable est obsolete, cote developpement, ils sont deja
> six mois plus loin, avec d'autres modifications... et une fois de plus, une
> version de dev qui ne compile pas chez toi. Il faut une patience de jesuite
> pour travailler avec eux dans ces conditions. Moi j'avoue, j'ai abandonne.
Je dois dire que moi aussi j'ai abandonn�, pas pour un probl�me de
patience mais tout simplement parce que je n'ai pas le temps de jouer �
ce jeu de chat et de souris (sans compter les gendarmes et les voleurs,
je veux parler de la cession de droits � la FSF quand il s'agit de code
que je n'ai pas �crit moi-m�me).
N�anmoins en te lisant, je me demande s'il ne serait pas plus facile
d'essayer de suivre GCC-HEAD uniquement en mode de compilateur crois�
(host=build=linux-i386, target=ta_cible_r�elle), ce qui a au moins
l'avantage de permettre aux autres d�veloppeurs de GCC de pouvoir
reproduire � facilement � le m�me environnement de test ?
Antoine
Marc Espie
Encore faut-il croire a la compilation croisee... l'air de rien, la compilation native,
c'est un des trucs qui stresse le plus un systeme d'exploitation.
sans compter qu'il y a toujours des petites differences dans les binaires produits en natif
et en compilation croisee... ni gcc ni les binutils ne sont exempts de bugs de ce point de vue.
Tous les systemes qui ont abandonne la compilation native, suite aux multiples ralentissements
de gcc, sont en train de mourir, car il y traine des bugs critiques pendant pas mal de mois.
L'exemple classique, c'est NetBSD vax, ou ils se sont rendu compte qu'il y avait
un gros souci et que le systeme ne pouvait plus faire de build natif... six mois apres que
le probleme a ete introduit dans l'arbre.
Jean-Marc Bourguet
Une chose que je n'ai pas suivi, c'est la tentative de faire revivre pcc.
Tu sais o� �a en est?
Marc Espie
Jean-Marc Bourguet <j...@bourguet.org> wrote:
>es...@lain.home (Marc Espie) writes:
>
>Une chose que je n'ai pas suivi, c'est la tentative de faire revivre pcc.
>Tu sais o� �a en est?
>
>A+
Ca avance lentement. Les bonnes volontes sont les bienvenues ;-)
Jean-Marc Bourguet
Si j'avais le temps et la motivation pour un projet de cette ampleur,
j'essaierais plut�t de voir comment r�cup�rer les info de d�bug et cr�er
des tags avec.