On voit souvent des "quel linux choisir ?", des "pourquoi linux ?" etc.
Mais finalement à devoir choisir entre la peste (du côté de chez MS) et
la grippe (notre bon vieux nunux), celà ne vous arrive pas le matin en
vous réveillant de vous dire que les programmes qui font fonctionner
votre machines ne sont que des bidouillages plus ou moins réussis ?
Regardez les codes sources d'un programme en C. Même le code d'un bon
programmeur n'est rempli que d'horreurs. Ce fameux "void" : c'est quoi
cette abomination de la programmation ? Il n'y a aucune sémantique
valable là derrière. D'ailleurs les types en C n'ont de type que le nom.
Comment se fait il qu'on puisse écrire dans la 11e case d'un tableau de
10 éléments. Ce langage surestime beaucoup les capacités des personnes
qui vont l'utiliser. Une telle chose ne doit pas être possible. Comment
imaginer que ce genre de choses peut être voulu par le programmeur ?
Je pense que vous avez déjà vu du JAVA. Mais c'est à gerber cet
emboîtement de new, cette masse colossale de classes à faire pour faire
trois fois rien ! J'ose même pas imaginer la quantité de calculs
inutiles faits par la machine pour gérer ces merdes. D'accord il y a de
l'optimisation, mais c'est loin d'être suffisant.
Dans le temps les programmes étaient bidouillés parce qu'il n'y avait
pas assez de mémoire : par exemple on utilisait une variable pour
stocker deux informations. Maintenant l'horreur est à l'autre extrême :
on a tellement de mémoire de disponible que l'on utilise trop. En C :
tant pis c'est perdu. Un trou de mémoire ? Tant que le pc doit pas
redémarrer toutes les heures à cause de ça on s'en fout. En JAVA : il y
a le ramasse miettes alors on peut bouffer de la mémoire : c'est pô grave.
Dès que les programmes ont commencé à ne plus rentrer sur une disquette
ils sont devenus beaucoup trop compliqués pour fonctionner correctement.
On en vient à une époque où on trouve acceptable un programme quand il a
moins de cent bugs alors que rien que le fait de consommer trop de
ressources fait que le programme n'est pas bon. Aujourd'hui on nous
parle de .NET et de merdouilles dans le genre. A quoi ça sert de se
lancer dans la création de langages qui se copient les uns les autres.
C, C++, JAVA, Pascal : c'est la même chose, la même façon de penser. Et
c'est une manière de penser qui pousse à faire des fautes.
Bref l'informatique ne va pas fort.
Je ne trouve pas. Tiens, voilà un langage de programmation pour toi : <URL:http://www.muppetlabs.com/~breadbox/bf/>
-- Les Wampas n'aiment pas la variété pourrie. Didier Wampas ______________________________________ attention à l'@ email antispam Macintosh, Linux Mac, Palm: http://webperso.easyconnect.fr/eherlent/ GNU/Linux sur Macintosh : http://www.linux-france.org/macintosh/
In article <422dd530$0$12530$636a15ce@news.free.fr>, Tom <tom@tom.com>
wrote:
Bref l'informatique ne va pas fort.
Je ne trouve pas.
Tiens, voilà un langage de programmation pour toi :
<URL:http://www.muppetlabs.com/~breadbox/bf/>
--
Les Wampas n'aiment pas la variété pourrie. Didier Wampas
______________________________________ attention à l'@ email antispam
Macintosh, Linux Mac, Palm: http://webperso.easyconnect.fr/eherlent/
GNU/Linux sur Macintosh : http://www.linux-france.org/macintosh/
Je ne trouve pas. Tiens, voilà un langage de programmation pour toi : <URL:http://www.muppetlabs.com/~breadbox/bf/>
-- Les Wampas n'aiment pas la variété pourrie. Didier Wampas ______________________________________ attention à l'@ email antispam Macintosh, Linux Mac, Palm: http://webperso.easyconnect.fr/eherlent/ GNU/Linux sur Macintosh : http://www.linux-france.org/macintosh/
JKB
Le 08-03-2005, à propos de Re: a-t-on le choix ?, Etienne Herlent écrivait dans fr.comp.os.linux.debats :
In article <422dd530$0$12530$, Tom wrote:
Bref l'informatique ne va pas fort.
Je ne trouve pas. Tiens, voilà un langage de programmation pour toi : <URL:http://www.muppetlabs.com/~breadbox/bf/>
Et goto++ dans tout ça ;-)
JKB
Le 08-03-2005, à propos de
Re: a-t-on le choix ?,
Etienne Herlent écrivait dans fr.comp.os.linux.debats :
In article <422dd530$0$12530$636a15ce@news.free.fr>, Tom <tom@tom.com>
wrote:
Bref l'informatique ne va pas fort.
Je ne trouve pas.
Tiens, voilà un langage de programmation pour toi :
<URL:http://www.muppetlabs.com/~breadbox/bf/>
Le 08-03-2005, à propos de Re: a-t-on le choix ?, Etienne Herlent écrivait dans fr.comp.os.linux.debats :
In article <422dd530$0$12530$, Tom wrote:
Bref l'informatique ne va pas fort.
Je ne trouve pas. Tiens, voilà un langage de programmation pour toi : <URL:http://www.muppetlabs.com/~breadbox/bf/>
Et goto++ dans tout ça ;-)
JKB
Joe Cool
Tom vient de nous annoncer :
Ce fameux "void" : c'est quoi cette abomination de la programmation ? Il n'y a aucune sémantique valable là derrière.
Tu as encore des choses à comprendre
Encore un qui n'a jamais lu une suele ligne de la (prétendue) norme C.
D'ailleurs les types en C n'ont de type que le nom. Comment se fait il qu'on puisse écrire dans la 11e case d'un tableau de 10 éléments. Ce langage surestime beaucoup les capacités des personnes qui vont l'utiliser. Une telle chose ne doit pas être possible. Comment imaginer que ce genre de choses peut être voulu par le programmeur ?
mon dieu mon dieu mon dieu
Un langage qui permet explicitement de faire planter une machine a forcément été conçu pour faire planter la machine.
Bref l'informatique ne va pas fort.
Developpe ton propre langage ideal puisque tu es si intelligent...
Mais de toute facon, le langage on s'en branle. Ce qui est primordial, c'est la conception. J'ai vu de tres beaux programmes, tres clairs, ecrit en assembleur. Et pourtant il y a difficilement pire que ce langage :-D
N'importe quel assembleur est plus portable et plus sûr que le C. Il suffit d'admirer les contorsions des gars charger du portage des applis C en 64 bits. C'est risible. Des langages meilleurs que le C on en trouve à la pelle, plus puissants, plus sûrs, pous simples, etc.
On ne peut pas sérieusement programmer avec un langage bricolé à la va-vite il y a plus de 35 ans. Ceux qui affirment le contraire ne méritent pas le nom d'informaticien.
-- Joe Cool
Tom vient de nous annoncer :
Ce fameux "void" : c'est quoi cette abomination de la programmation ?
Il n'y a aucune sémantique valable là derrière.
Tu as encore des choses à comprendre
Encore un qui n'a jamais lu une suele ligne de la (prétendue) norme C.
D'ailleurs les types en C n'ont de type que le nom. Comment se fait il
qu'on puisse écrire dans la 11e case d'un tableau de 10 éléments. Ce
langage surestime beaucoup les capacités des personnes qui vont
l'utiliser. Une telle chose ne doit pas être possible. Comment
imaginer que ce genre de choses peut être voulu par le programmeur ?
mon dieu mon dieu mon dieu
Un langage qui permet explicitement de faire planter une machine a
forcément été conçu pour faire planter la machine.
Bref l'informatique ne va pas fort.
Developpe ton propre langage ideal puisque tu es si intelligent...
Mais de toute facon, le langage on s'en branle. Ce qui est primordial,
c'est la conception. J'ai vu de tres beaux programmes, tres clairs,
ecrit en assembleur. Et pourtant il y a difficilement pire que ce
langage :-D
N'importe quel assembleur est plus portable et plus sûr que le C. Il
suffit d'admirer les contorsions des gars charger du portage des applis
C en 64 bits. C'est risible. Des langages meilleurs que le C on en
trouve à la pelle, plus puissants, plus sûrs, pous simples, etc.
On ne peut pas sérieusement programmer avec un langage bricolé à la
va-vite il y a plus de 35 ans. Ceux qui affirment le contraire ne
méritent pas le nom d'informaticien.
Ce fameux "void" : c'est quoi cette abomination de la programmation ? Il n'y a aucune sémantique valable là derrière.
Tu as encore des choses à comprendre
Encore un qui n'a jamais lu une suele ligne de la (prétendue) norme C.
D'ailleurs les types en C n'ont de type que le nom. Comment se fait il qu'on puisse écrire dans la 11e case d'un tableau de 10 éléments. Ce langage surestime beaucoup les capacités des personnes qui vont l'utiliser. Une telle chose ne doit pas être possible. Comment imaginer que ce genre de choses peut être voulu par le programmeur ?
mon dieu mon dieu mon dieu
Un langage qui permet explicitement de faire planter une machine a forcément été conçu pour faire planter la machine.
Bref l'informatique ne va pas fort.
Developpe ton propre langage ideal puisque tu es si intelligent...
Mais de toute facon, le langage on s'en branle. Ce qui est primordial, c'est la conception. J'ai vu de tres beaux programmes, tres clairs, ecrit en assembleur. Et pourtant il y a difficilement pire que ce langage :-D
N'importe quel assembleur est plus portable et plus sûr que le C. Il suffit d'admirer les contorsions des gars charger du portage des applis C en 64 bits. C'est risible. Des langages meilleurs que le C on en trouve à la pelle, plus puissants, plus sûrs, pous simples, etc.
On ne peut pas sérieusement programmer avec un langage bricolé à la va-vite il y a plus de 35 ans. Ceux qui affirment le contraire ne méritent pas le nom d'informaticien.
-- Joe Cool
Joe Cool
Bon, je reconnais que sa syntaxe a quelques problèmes, en particulier les opérateurs pour les flottants...
Sans ce « problème » de syntaxe, le système de type s'effondre. Ce n'est donc pas un problème, mais une garantie de bon fonctionnement.
-- Joe Cool
Bon, je
reconnais que sa syntaxe a quelques problèmes, en particulier les
opérateurs pour les flottants...
Sans ce « problème » de syntaxe, le système de type s'effondre. Ce n'est
donc pas un problème, mais une garantie de bon fonctionnement.
Bon, je reconnais que sa syntaxe a quelques problèmes, en particulier les opérateurs pour les flottants...
Sans ce « problème » de syntaxe, le système de type s'effondre. Ce n'est donc pas un problème, mais une garantie de bon fonctionnement.
-- Joe Cool
Joe Cool
Tom wrote:
Regardez les codes sources d'un programme en C. Même le code d'un bon programmeur n'est rempli que d'horreurs. Ce fameux "void" : c'est quoi cette abomination de la programmation ? Il n'y a aucune sémantique valable là derrière. D'ailleurs les types en C n'ont de type que le nom. Comment se fait il qu'on puisse écrire dans la 11e case d'un tableau de 10 éléments. Ce langage surestime beaucoup les capacités des personnes qui vont l'utiliser. Une telle chose ne doit pas être possible. Comment imaginer que ce genre de choses peut être voulu par le programmeur ?
Et encore un troll qui n'a rien à faire ici. Z'avez rien de mieux à faire ?
Encore un endoctriné qui dénigre ce qu'il ne comprend pas au lieu d'argumenter. Vérifiez donc votre pilosité avant de vous occuper de celle des autres.
-- Joe Cool
Tom <tom@tom.com> wrote:
Regardez les codes sources d'un programme en C. Même le code d'un bon
programmeur n'est rempli que d'horreurs. Ce fameux "void" : c'est quoi
cette abomination de la programmation ? Il n'y a aucune sémantique
valable là derrière. D'ailleurs les types en C n'ont de type que le
nom. Comment se fait il qu'on puisse écrire dans la 11e case d'un
tableau de 10 éléments. Ce langage surestime beaucoup les capacités
des personnes qui vont l'utiliser. Une telle chose ne doit pas être
possible. Comment imaginer que ce genre de choses peut être voulu par
le programmeur ?
Et encore un troll qui n'a rien à faire ici. Z'avez rien de mieux à
faire ?
Encore un endoctriné qui dénigre ce qu'il ne comprend pas au lieu
d'argumenter. Vérifiez donc votre pilosité avant de vous occuper de
celle des autres.
Regardez les codes sources d'un programme en C. Même le code d'un bon programmeur n'est rempli que d'horreurs. Ce fameux "void" : c'est quoi cette abomination de la programmation ? Il n'y a aucune sémantique valable là derrière. D'ailleurs les types en C n'ont de type que le nom. Comment se fait il qu'on puisse écrire dans la 11e case d'un tableau de 10 éléments. Ce langage surestime beaucoup les capacités des personnes qui vont l'utiliser. Une telle chose ne doit pas être possible. Comment imaginer que ce genre de choses peut être voulu par le programmeur ?
Et encore un troll qui n'a rien à faire ici. Z'avez rien de mieux à faire ?
Encore un endoctriné qui dénigre ce qu'il ne comprend pas au lieu d'argumenter. Vérifiez donc votre pilosité avant de vous occuper de celle des autres.
-- Joe Cool
Nicolas George
Tom , dans le message <422dd530$0$12530$, a écrit :
la grippe (notre bon vieux nunux)
Grippe toi-même.
Regardez les codes sources d'un programme en C. Même le code d'un bon programmeur n'est rempli que d'horreurs.
C'est faux.
Ce fameux "void" : c'est quoi cette abomination de la programmation ? Il n'y a aucune sémantique valable là derrière.
Si : il correspond à une tournure impérative et pas interrogative, il a à peu près autant de sens qu'un point d'exclamation par rapport à un point d'interrogation.
Comment se fait il qu'on puisse écrire dans la 11e case d'un tableau de 10 éléments.
On ne peut pas, tu te trompes.
Ce langage surestime beaucoup les capacités des personnes qui vont l'utiliser.
Quand c'est toi qui l'écris, probablement, en effet. Quand c'est moi, ce n'est pas le cas.
Je pense que vous avez déjà vu du JAVA. Mais c'est à gerber
Java est un langage de merde, on est d'accord.
En C : tant pis c'est perdu. Un trou de mémoire ?
Tous les programmeurs ne sont pas aussi laxistes, loin de là.
En JAVA : il y a le ramasse miettes alors on peut bouffer de la mémoire
Le moment où une resource n'est plus utile n'est pas forcément décidable statiquement, la présence d'un GC est donc parfois nécessaire de toutes façons.
Dès que les programmes ont commencé à ne plus rentrer sur une disquette ils sont devenus beaucoup trop compliqués pour fonctionner correctement.
C'est parfaitement faux. Au contraire, les contraintes de taille plus faibles permettent une programmation plus modulaire et plus claire, donc des programmes plus simples qui font pourtant plus de choses.
Tom , dans le message <422dd530$0$12530$636a15ce@news.free.fr>, a
écrit :
la grippe (notre bon vieux nunux)
Grippe toi-même.
Regardez les codes sources d'un programme en C. Même le code d'un bon
programmeur n'est rempli que d'horreurs.
C'est faux.
Ce fameux "void" : c'est quoi
cette abomination de la programmation ? Il n'y a aucune sémantique
valable là derrière.
Si : il correspond à une tournure impérative et pas interrogative, il a à
peu près autant de sens qu'un point d'exclamation par rapport à un point
d'interrogation.
Comment se fait il qu'on puisse écrire dans la 11e case d'un tableau de
10 éléments.
On ne peut pas, tu te trompes.
Ce langage surestime beaucoup les capacités des personnes
qui vont l'utiliser.
Quand c'est toi qui l'écris, probablement, en effet. Quand c'est moi, ce
n'est pas le cas.
Je pense que vous avez déjà vu du JAVA. Mais c'est à gerber
Java est un langage de merde, on est d'accord.
En C :
tant pis c'est perdu. Un trou de mémoire ?
Tous les programmeurs ne sont pas aussi laxistes, loin de là.
En JAVA : il y
a le ramasse miettes alors on peut bouffer de la mémoire
Le moment où une resource n'est plus utile n'est pas forcément décidable
statiquement, la présence d'un GC est donc parfois nécessaire de toutes
façons.
Dès que les programmes ont commencé à ne plus rentrer sur une disquette
ils sont devenus beaucoup trop compliqués pour fonctionner correctement.
C'est parfaitement faux. Au contraire, les contraintes de taille plus
faibles permettent une programmation plus modulaire et plus claire, donc des
programmes plus simples qui font pourtant plus de choses.
Tom , dans le message <422dd530$0$12530$, a écrit :
la grippe (notre bon vieux nunux)
Grippe toi-même.
Regardez les codes sources d'un programme en C. Même le code d'un bon programmeur n'est rempli que d'horreurs.
C'est faux.
Ce fameux "void" : c'est quoi cette abomination de la programmation ? Il n'y a aucune sémantique valable là derrière.
Si : il correspond à une tournure impérative et pas interrogative, il a à peu près autant de sens qu'un point d'exclamation par rapport à un point d'interrogation.
Comment se fait il qu'on puisse écrire dans la 11e case d'un tableau de 10 éléments.
On ne peut pas, tu te trompes.
Ce langage surestime beaucoup les capacités des personnes qui vont l'utiliser.
Quand c'est toi qui l'écris, probablement, en effet. Quand c'est moi, ce n'est pas le cas.
Je pense que vous avez déjà vu du JAVA. Mais c'est à gerber
Java est un langage de merde, on est d'accord.
En C : tant pis c'est perdu. Un trou de mémoire ?
Tous les programmeurs ne sont pas aussi laxistes, loin de là.
En JAVA : il y a le ramasse miettes alors on peut bouffer de la mémoire
Le moment où une resource n'est plus utile n'est pas forcément décidable statiquement, la présence d'un GC est donc parfois nécessaire de toutes façons.
Dès que les programmes ont commencé à ne plus rentrer sur une disquette ils sont devenus beaucoup trop compliqués pour fonctionner correctement.
C'est parfaitement faux. Au contraire, les contraintes de taille plus faibles permettent une programmation plus modulaire et plus claire, donc des programmes plus simples qui font pourtant plus de choses.
Nicolas George
Tom , dans le message <422de1e1$0$30583$, a écrit :
Le manque de pérénité de sa syntaxe ne plaide pas en sa faveur. Quand on pense en C on ne peut pas comprendre la syntaxe d'un langage
comme Caml.
Et quand on ne pense pas du tout, on finit par ranter pendant des lignes et des lignes complètement à côté de la plaque. Je te suggère de chercher « pérennité » dans un dictionnaire.
Tom , dans le message <422de1e1$0$30583$636a15ce@news.free.fr>, a
écrit :
Le manque de pérénité de sa syntaxe ne plaide pas en sa faveur.
Quand on pense en C on ne peut pas comprendre la syntaxe d'un langage
comme Caml.
Et quand on ne pense pas du tout, on finit par ranter pendant des lignes et
des lignes complètement à côté de la plaque. Je te suggère de chercher
« pérennité » dans un dictionnaire.
Tom , dans le message <422de1e1$0$30583$, a écrit :
Le manque de pérénité de sa syntaxe ne plaide pas en sa faveur. Quand on pense en C on ne peut pas comprendre la syntaxe d'un langage
comme Caml.
Et quand on ne pense pas du tout, on finit par ranter pendant des lignes et des lignes complètement à côté de la plaque. Je te suggère de chercher « pérennité » dans un dictionnaire.
Nicolas George
Joe Cool , dans le message <422de975$0$27862$, a écrit :
Un langage qui permet explicitement de faire planter une machine a forcément été conçu pour faire planter la machine.
Le C ne permet pas de faire planter une machine.
N'importe quel assembleur est plus portable et plus sûr que le C.
Ce qu'il ne faut pas lire. Vas-y, fais tourner un programme en assembleur 68000 sur une plateforme intel qu'on rigole.
Il suffit d'admirer les contorsions des gars charger du portage des applis C en 64 bits.
Il n'y a aucune contorsions à faire en C.
C'est risible.
Une telle méconnaissance, effectivement, c'est risible.
Joe Cool , dans le message <422de975$0$27862$626a14ce@news.free.fr>, a
écrit :
Un langage qui permet explicitement de faire planter une machine a
forcément été conçu pour faire planter la machine.
Le C ne permet pas de faire planter une machine.
N'importe quel assembleur est plus portable et plus sûr que le C.
Ce qu'il ne faut pas lire. Vas-y, fais tourner un programme en assembleur
68000 sur une plateforme intel qu'on rigole.
Il
suffit d'admirer les contorsions des gars charger du portage des applis
C en 64 bits.
Il n'y a aucune contorsions à faire en C.
C'est risible.
Une telle méconnaissance, effectivement, c'est risible.
Joe Cool , dans le message <422de975$0$27862$, a écrit :
Un langage qui permet explicitement de faire planter une machine a forcément été conçu pour faire planter la machine.
Le C ne permet pas de faire planter une machine.
N'importe quel assembleur est plus portable et plus sûr que le C.
Ce qu'il ne faut pas lire. Vas-y, fais tourner un programme en assembleur 68000 sur une plateforme intel qu'on rigole.
Il suffit d'admirer les contorsions des gars charger du portage des applis C en 64 bits.
Il n'y a aucune contorsions à faire en C.
C'est risible.
Une telle méconnaissance, effectivement, c'est risible.
JKB
Le 08-03-2005, à propos de Re: a-t-on le choix ?, Nicolas George écrivait dans fr.comp.os.linux.debats :
Joe Cool , dans le message <422de975$0$27862$, a écrit :
Un langage qui permet explicitement de faire planter une machine a forcément été conçu pour faire planter la machine.
Le C ne permet pas de faire planter une machine.
Ah bon ? Dans ce cas, d'où provient un kernel panic ? Le C ne permet pas de faire planter une machine dès lors que le code généré tourne en _userland_.
N'importe quel assembleur est plus portable et plus sûr que le C.
Ce qu'il ne faut pas lire. Vas-y, fais tourner un programme en assembleur 68000 sur une plateforme intel qu'on rigole.
On utilise la technique qui permet de faire tourner de l'assembleur VAX sur Alpha ;-)
suffit d'admirer les contorsions des gars charger du portage des applis C en 64 bits.
Il n'y a aucune contorsions à faire en C.
Si le C est _bien_ écrit avec des typedef dans tous les sens pour définir des objets de taille et de structure connues ! Sinon, faire tourner un code écrit en C avec des int d'une architecture 32 bits vers une 64 est une gageure ! Il suffit de voir les bugs du noyau Linux sur sparc64 pour s'en rendre compte (surtout vers netfilter qui interagit tès mal avec iproute2 à cause de problèmes de ce type et je pense aussi de problèmes petit/grand boutiste).
JKB
Le 08-03-2005, à propos de
Re: a-t-on le choix ?,
Nicolas George écrivait dans fr.comp.os.linux.debats :
Joe Cool , dans le message <422de975$0$27862$626a14ce@news.free.fr>, a
écrit :
Un langage qui permet explicitement de faire planter une machine a
forcément été conçu pour faire planter la machine.
Le C ne permet pas de faire planter une machine.
Ah bon ? Dans ce cas, d'où provient un kernel panic ? Le C ne permet
pas de faire planter une machine dès lors que le code généré tourne
en _userland_.
N'importe quel assembleur est plus portable et plus sûr que le C.
Ce qu'il ne faut pas lire. Vas-y, fais tourner un programme en assembleur
68000 sur une plateforme intel qu'on rigole.
On utilise la technique qui permet de faire tourner de l'assembleur
VAX sur Alpha ;-)
suffit d'admirer les contorsions des gars charger du portage des applis
C en 64 bits.
Il n'y a aucune contorsions à faire en C.
Si le C est _bien_ écrit avec des typedef dans tous les sens pour
définir des objets de taille et de structure connues ! Sinon, faire
tourner un code écrit en C avec des int d'une architecture 32 bits
vers une 64 est une gageure ! Il suffit de voir les bugs du noyau
Linux sur sparc64 pour s'en rendre compte (surtout vers netfilter
qui interagit tès mal avec iproute2 à cause de problèmes de ce type
et je pense aussi de problèmes petit/grand boutiste).
Le 08-03-2005, à propos de Re: a-t-on le choix ?, Nicolas George écrivait dans fr.comp.os.linux.debats :
Joe Cool , dans le message <422de975$0$27862$, a écrit :
Un langage qui permet explicitement de faire planter une machine a forcément été conçu pour faire planter la machine.
Le C ne permet pas de faire planter une machine.
Ah bon ? Dans ce cas, d'où provient un kernel panic ? Le C ne permet pas de faire planter une machine dès lors que le code généré tourne en _userland_.
N'importe quel assembleur est plus portable et plus sûr que le C.
Ce qu'il ne faut pas lire. Vas-y, fais tourner un programme en assembleur 68000 sur une plateforme intel qu'on rigole.
On utilise la technique qui permet de faire tourner de l'assembleur VAX sur Alpha ;-)
suffit d'admirer les contorsions des gars charger du portage des applis C en 64 bits.
Il n'y a aucune contorsions à faire en C.
Si le C est _bien_ écrit avec des typedef dans tous les sens pour définir des objets de taille et de structure connues ! Sinon, faire tourner un code écrit en C avec des int d'une architecture 32 bits vers une 64 est une gageure ! Il suffit de voir les bugs du noyau Linux sur sparc64 pour s'en rendre compte (surtout vers netfilter qui interagit tès mal avec iproute2 à cause de problèmes de ce type et je pense aussi de problèmes petit/grand boutiste).
JKB
Nicolas George
JKB , dans le message , a écrit :
Ah bon ? Dans ce cas, d'où provient un kernel panic ?
Tu parles du noyau Linux ? Il n'est pas en C. Il est écrit dans un langage qui a une syntaxe qui ressemble considérablement à celle du C, et certains bouts du code sont du code C valide, mais ce n'est pas, stricto sensu, du C.
Si le C est _bien_ écrit avec des typedef dans tous les sens pour définir des objets de taille et de structure connues !
Non. Un code qui dépend de la taille des objets de manière incontrôlée ne peut pas être du C valide.
JKB , dans le message <slrnd2rr3l.mkg.knatschke@rayleigh.systella.fr>, a
écrit :
Ah bon ? Dans ce cas, d'où provient un kernel panic ?
Tu parles du noyau Linux ? Il n'est pas en C. Il est écrit dans un langage
qui a une syntaxe qui ressemble considérablement à celle du C, et certains
bouts du code sont du code C valide, mais ce n'est pas, stricto sensu, du C.
Si le C est _bien_ écrit avec des typedef dans tous les sens pour
définir des objets de taille et de structure connues !
Non. Un code qui dépend de la taille des objets de manière incontrôlée ne
peut pas être du C valide.
Ah bon ? Dans ce cas, d'où provient un kernel panic ?
Tu parles du noyau Linux ? Il n'est pas en C. Il est écrit dans un langage qui a une syntaxe qui ressemble considérablement à celle du C, et certains bouts du code sont du code C valide, mais ce n'est pas, stricto sensu, du C.
Si le C est _bien_ écrit avec des typedef dans tous les sens pour définir des objets de taille et de structure connues !
Non. Un code qui dépend de la taille des objets de manière incontrôlée ne peut pas être du C valide.
