Drole de main()

In article <4b2e08d3$0$29988$426a34cc@news.free.fr>,
Samuel Devulder <samuel-dot-devulder@geensys.com> wrote:

Wykaaa a écrit :

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....)

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)

Marc Espie a écrit :

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.

Samuel Devulder a écrit :

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.

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).

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.

Samuel Devulder <samuel-dot-devulder@geensys.com> writes:

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).

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 a écrit :

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 !

Samuel Devulder écrivit :

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

In article <hgnjqd$j9$1@shakotay.alphanet.ch>,
Antoine Leca <root@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...

Marc Espie écrivit :

Les gens de gcc pratiquent l'obsolescence rapide.

<couic>

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

In article <hgo99g$k44$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> wrote:

Marc Espie écrivit :

Les gens de gcc pratiquent l'obsolescence rapide.

<couic>

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 ?

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.