Discussion :

[SofEvans]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
 
int* p = 0;
int i = *p; // .... et la?
//ou bien
int& ref = *p; // .... et la? Une référence est censé être toujours valide non?

Régle n°1 quand on déréference un pointeur pouvant être NULL : on test si le pointeur est NULL avant de déréférencer.

Navré d'être brutale, mais là ton exemple c'est juste absolument n'importe quoi.
C'est comme si j'ecrivais

char *chaine = "quarante-deux";
int nombre = *chaine;

et que je disais que l'erreur de design du langage fait que nombre ne vaille pas 42.

Ensuite ton deuxième exemple n'est même pas du C.

Pour finir, depuis quand une référence, en langage C, est-elle toujours censé être valide ? Et c'est quoi cette référence d'ailleurs ? Un autre nom des pointeurs ?

[transgohan]

A oui? Je te pari que je reprends l'ensemble du code que tu as produit et je trouve le contre exemple

Je n'ai jamais affirmé que je codais sans bug.
Et je considère effectivement quand je corrige l'un de mes bugs que je suis devant un problème d'interface chaise-clavier et non devant un problème de langage.

Si le langage résolvait tout on aurait créé une énième religion je crois.

Vous ne devez pas vous souciez de l'argent que les bugs coûte à une société.
Arrêter de penser que vous êtes des génies qui ne faite aucune erreur sérieux, c'est n'importe quoi.
BEAUCOUP de programmeurs ont le même discours et pourtant il n'y a pas moins de bugs/crashs... J'embauche des gens dans des équipes de dev car je suis lead et je te jure que des réponses comme ça c'est un NON pour intégrer une équipe de dev...

Oh que si... C'est pour cela qu'on embauche des testeurs de différents niveaux, qu'on paie des licences d'outils d'analyse statique et dynamique de code et j'en passe...

En tout cas une chose est sûre, je n'aimerai pas travailler avec quelqu'un comme toi...
Si la place à l'erreur n'est pas acceptable c'est que tu as zéro tolérance et que tu licencies tous les jours.

[Pyramidev]

Désolé d'être si têtu et d'avoir du mal à comprendre, mais pourquoi ce code ne serait-il pas correct ?

Ce code en C est correct. Ce que je voulais dire, c'est que si tu remplaces le code correct :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
config_s *userConfig = User_GetConfig(&userList[i]);
if (userConfig) {
	printf("The config content of this user is %d.\n", userConfig->content);
} else {
	printf("This user does not have any config.\n");
}

par le code incorrect :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
config_s *userConfig = User_GetConfig(&userList[i]);
printf("The config content of this user is %d.\n", userConfig->content);

alors tu auras une erreur au runtime au lieu d'une erreur à la compilation.

Donc pour résumer tu demandes à ce que le langage fasse le boulot du développeur.
Quand une fonction retourne une adresse, on teste toujours que l'adresse n'est pas nulle.

Il va alors faire comme si le pointeur retourné n'était jamais nul.

Je répète... Ce n'est pas un problème de langage mais d'interface chaise-clavier à ce niveau là...

Je n'ai jamais affirmé que je codais sans bug.
Et je considère effectivement quand je corrige l'un de mes bugs que je suis devant un problème d'interface chaise-clavier et non devant un problème de langage.

Oh que si... C'est pour cela qu'on embauche des testeurs de différents niveaux, qu'on paie des licences d'outils d'analyse statique et dynamique de code et j'en passe...

Il y a une contradiction intéressante dans ces messages.

D'un côté, tu admets faire parfois des étourderies et, parmi les moyens de détecter ces étourderies, tu reconnais la valeur de certains outils d'analyse statique de code. Il n'y a donc pas besoin de t'expliquer, par exemple, que désactiver tous les avertissements du compilateur serait une mauvaise pratique. Tu as compris qu'avoir des outils d'analyse statique du code est souhaitable pour améliorer la productivité.

Et pourtant, d'un autre côté, quand je présente une fonctionnalité d'un langage autre que C qui permet d'éviter les étourderies de pointeurs nuls, tu juges que ce n'est pas au langage de faire ce travail, mais au développeur. Pourtant, les contrôles faits par le compilateur d'un langage ne sont qu'un cas particulier d'analyse statique du code.

J'y vois ici un biais de résistance au changement.

[Astraya]

Régle n°1 quand on déréference un pointeur pouvant être NULL : on test si le pointeur est NULL avant de déréférencer.

Navré d'être brutale, mais là ton exemple c'est juste absolument n'importe quoi.
C'est comme si j'ecrivais



et que je disais que l'erreur de design du langage fait que nombre ne vaille pas 42.

Ensuite ton deuxième exemple n'est même pas du C.

Pour finir, depuis quand une référence, en langage C, est-elle toujours censé être valide ? Et c'est quoi cette référence d'ailleurs ? Un autre nom des pointeurs ?

Et qui va vérifier ta règle? Toi? Un autre programmeur? Est-ce que la personne qui va relire le code est sur à 100% et est bine réveillé?
Règle n°1 ; Arrêter donner au programmeur la possibilité de faire des choses que le compilateur devrait interdire!

La référence est un abus de langage de ma part qui vient du C++. C'est un pointeur qui ne peut pas être nul, créer une référence nul crash. Et c'est ici, un problème hérité du C

[rt15]

Concernant les pointeurs nulls, il y a deux sujets.

Le premier, c'est les pointeurs nulls et la "billion-dollar mistake" de les avoir inventés.
Cette erreur ne s'applique pas seulement au C, mais aussi au Java et au C# par exemple.
Le problème est que les pointeurs (ou références) nulls peuvent générer des erreurs (NullPointerException en Java, NullReferenceException en C#) à l'exécution.
Les compilateurs protègent mal contre ces erreurs même si on peut améliorer les choses avec les annotations (@CheckForNull...) + analyse statiques en Java (Sonar....) et C# 8 introduit les références nullables.

Cette erreur d'avoir introduit les pointeurs nulls s'appliquent surtout aux langages de haut niveau et a coûté effectivement très cher.
En C qui est plus bas niveau c'est très cohérent d'avoir ces pointeurs nulls.
Contrairement au Java/C#, le problème en C ne se résume pas aux pointeurs nulls. On peut aussi avoir très facilement des pointeurs qui pointent au mauvais endroit. (Après la fin d'un tableau, sur de la mémoire libérée...)

Le deuxième sujet sur le fait que null correspond à la valeur 0 je ne comprends pas trop.
Peut être que Astraya mélange avec un exploit qui se base sur le déréférencement de pointeurs nulls.
Cet exploit a été (est ?) utilisé par les hacker pour faire des élévations de privilège.

Comme ce n'est que pour de l'élévation de privilège, le hacker doit s'être déjà introduit dans un processus, par exemple en exploitant une faille de type stack buffer overflow.
Ensuite, le hacker map de la mémoire à l'adresse 0 dans ce processus. Ce n'est pas toujours possible, certains systèmes d'exploitations ne le permettent pas ou plus.
À l'adresse 0, le hacker met en place son shell code.
Ensuite, le hacker fait un appel système en lui donnant un pointeur null (qui ne doit pas être vérifié par le kernel) et qui doit être utilisé comme adresse d'une fonction à appeler par le noyau (de préférence, mais ça peut aussi être des données même si c'est moins pratique).
Le noyau va appeler le shell code à l'adresse 0. Ce shell code sera exécuté par le noyau avec tous les privilèges.
Cet exploit profite du fonctionnement interne du système d'exploitation, de la gestion de la mémoire et des appels systèmes.
Pour rappel, le noyau est mappé (mais inaccessible) dans tous les processus utilisateurs, "au début" de la mémoire (donc juste après la mémoire 0).
Quand on fait un appel système, le mapping du user space est conservé lorsque la fonction du noyau s'exécute, pour des raisons de performance.
Donc ce qui se trouve à l'adresse 0 dans le processus utilisateur se trouve à l'adresse 0 et accessible dans l'appel du noyau correspondant (mais si un autre processus fait un appel système, il n'y aura pas la même chose à l'adresse 0 dans le kernel).

Pour résumé, cette faille (grave) reste peu utilisée et ne fait que de l'élévation de privilège donc elle reste marginale par rapport au dépassement de tampon par exemple.

https://utcc.utoronto.ca/~cks/space/...ageZeroProblem
https://blog.xpnsec.com/hevd-null-pointer/
Je suis tombé sur ce message où Linus dit qu'il ne veut pas "corriger".

Concernant Rust comme remplaçant du C, je vous propose de jeter un oeil sur les dernières lignes de ce fichier :
https://github.com/rust-lang/rust/bl...sys/unix/fd.rs

On est dans le coeur de Rust, et ce qu'il se passe lors de l'appel d'un destructeur d'un descripteur de fichier.
Rust ne vérifie pas la valeur de retour !
C'est une erreur de programmation.

Mais le problème est beaucoup plus profond que ça.
Pourquoi la valeur de retour n'est elle pas vérifiée ?
Car Rust ne serait pas quoi faire de l'erreur !
C'est un problème similaire au RAII du C++ qui ne sait pas quoi faire des exceptions dans les destructeurs.

Rust a pris selon moi une très mauvaise décision avec la destruction implicite des ressources similaire au RAII du C++.
Ils auraient dû imposer une destruction explicite et imposer la gestion des erreurs. drop devrait retourner quelque chose comme Result<(), Error>.
Le compilateur devrait vérifier que l'on appelle les destructeurs. Pas les appeler pour nous.


À part ça ce qui m'intéresse dans le vieux C c'est qu'il n'évolue plus, ou du moins que l'on peut se passer de ses évolutions.
Cela fait qu'un très vieux code est encore au goût du jour, lol !
Ce qu'il manque dans le C, ce n'est pas du tout les dernière innovation à la mode, c'est les trucs bien bas niveau.
Les compilateurs compensent les manques mais du coup c'est chiant de faire du code portable, genre __sync_fetch_and_or de gcc, _InterlockedOr de VC ou encore __builtin_bswap16 de gcc et _byteswap_ushort de VC.
Genre l'asm dans le C sous gcc qui n'a rien à voir avec l'asm dans le C sous VC.
La librairie standard d'origine est un peu une usine à bug aussi genre scanf qui semble conçu pour permettre au hacker de faire des dépassements de tampons ou strtok qui ne supporte pas d'être appelée depuis plusieurs threads.

L'autre point génial du C c'est les performances bien sûr et la qualité du code machine généré qui contient peu (mais quand même trop !) de choses rajoutées dans le dos du développeur.

[Astraya]

Je n'ai jamais affirmé que je codais sans bug.
Et je considère effectivement quand je corrige l'un de mes bugs que je suis devant un problème d'interface chaise-clavier et non devant un problème de langage.

Si le langage résolvait tout on aurait créé une énième religion je crois.

Des langages y tendent, C++ à grandement limité les fuites mémoires avec RAII et destructeur.
Rust présente une autre approche avec le Borrow checker et le système de ownership.

Oh que si... C'est pour cela qu'on embauche des testeurs de différents niveaux, qu'on paie des licences d'outils d'analyse statique et dynamique de code et j'en passe...

Dans quel boite tu travailles? Tu sais combien ça coûte un testeur juste pour trouver un NULL pointer et le temps nécessaire pour le corriger?
Dans les SSII autant dire que le test est le dernier de leur souci.
Dans le jeu vidéo c'est pour tester le jeux et relever les crashs/bug qu'on embauche et on se passerait volontiers de passer des heures à chercher une corruption mémoire et des crashs pour NULL pointer, use after free etc... (Et je parle de AAA).
Les outils ne font pas tout, et je t’amène à une réflexion de Microsoft sur le sujet ici: https://msrc-blog.microsoft.com/2019...e-secure-code/ ( Particulièrement "So many tools, so little time" )

En tout cas une chose est sûre, je n'aimerai pas travailler avec quelqu'un comme toi...
Si la place à l'erreur n'est pas acceptable c'est que tu as zéro tolérance et que tu licencies tous les jours.

C'est dommage en effet, mais tu n'as pas l'air de comprendre mes propos. J'ai passé mon temps à dire sur ce fil que le programmeur fait des erreurs car il peut être fatigué, malade, la tête ailleurs et que le langage n'aide pas.
Ai-je dis que c'était inacceptable? Qu'on doit le blâmer? Lui rejeter la faute?
Ton gamin n'a pas dormi de la nuit, tu oublies un free, tu es viré? laisse moi rire. Mais bon tu as l'air jeune...
Un collègue qui réponds simplement que le problème est entre la chaîne et le clavier n'aura rien a faire avec moi en effet


Mais bon je ne suis pas pour parler de ça mais des problèmes et avantages du C.
Ça devient stérile comme débat.

[SofEvans]

Ce code en C est correct. Ce que je voulais dire, c'est que si tu remplaces le code correct :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
config_s *userConfig = User_GetConfig(&userList[i]);
if (userConfig) {
	printf("The config content of this user is %d.\n", userConfig->content);
} else {
	printf("This user does not have any config.\n");
}

par le code incorrect :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
config_s *userConfig = User_GetConfig(&userList[i]);
printf("The config content of this user is %d.\n", userConfig->content);

alors tu auras une erreur au runtime au lieu d'une erreur à la compilation.

On est toutafé d'accord.

J'irais même plus loin : le langage C aujourd'hui n'est plus du tout adapté au marché du travail (hormis niche spécifique).
J'adore le langage C, j'en fais encore pour mes délires de projets perso, mais je sais aussi ouvrir les yeux : les avantage du C (la vitesse d’exécution, l'empreinte mémoire réduite, la simplicité) sont de moins en pertinents.
Il est préférable d'avoir un langage moins rapide que le C (mais rapide tout de même) qui va apporter des mécanisme de protection ou de détection d'erreur le plus tôt possible, de préférence à la compilation ou par analyse statique.
Et ce n'est que le début d'une liste en défaveur du C dans l'industrie (sauf celle de niche, encore une fois).

Cependant, ma réaction sur ce sujet est uniquement dû à la phrase

- Le pointeur pouvant être affecté à 0 est la plus grosse erreur de design.

que je ne comprends toujours pas, étant donné que le pointeur pouvant être affecté à 0 (NULL) est justement vitale.

Et qui va vérifier ta règle? Toi? Un autre programmeur? Est-ce que la personne qui va relire le code est sur à 100% et est bine réveillé?
Règle n°1 ; Arrêter donner au programmeur la possibilité de faire des choses que le compilateur devrait interdire!

La référence est un abus de langage de ma part qui vient du C++. C'est un pointeur qui ne peut pas être nul, créer une référence nul crash. Et c'est ici, un problème hérité du C

Créer un pointeur NULL et le déréférencer crash aussi.
Je trouve que ton argumentaire est un peu de mauvaise foi, même si, comme pour Pyramidev, je suis d'accord sur le fait que sacrifier les avantages du C (rapidité, mémoire, simplicité) en faveurs de plus de garde-fous, de contrôle (etc etc) est un must-have.
Néanmoins, quand on fait du C, on doit être rigoureux. Plus que dans d'autres langage.
Donc quand on manipule des pointeurs, on test si ceux-ci peuvent être NULL.

Et une fois le programme fini, on déroule les tests.
Et dans les tests, il doit au moins y avoir valgrind ou Dr Memory histoire de voir si les pointeurs ont été correctement géré.

C'est sûr, c'est plus long, c'est moins adapté à l'industrie actuel, mais c'est vitale, parce que sinon il suffit d'une erreur d'inattention pour faire un sigsev.
Mais bon, c'est pas comme si on pouvait pas faire des erreurs d'inattentions dans d'autres langages.

[Astraya]

On est dans le coeur de Rust, et ce qu'il se passe lors de l'appel d'un destructeur d'un descripteur de fichier.
Rust ne vérifie pas la valeur de retour !
C'est une erreur de programmation.

Mais le problème est beaucoup plus profond que ça.
Pourquoi la valeur de retour n'est elle pas vérifiée ?
Car Rust ne serait pas quoi faire de l'erreur !
C'est un problème similaire au RAII du C++ qui ne sait pas quoi faire des exceptions dans les destructeurs.

C'est petit ça . Et comment tu fais en C?
La valeur n'est pas vérifié car qu'est ce que tu ferais avec? Appeler close une seconde fois sur un EINTR? nop je conseille pas car tu peux fermer un autre descriptor...
Sur un EIO? Rust est thread safe, ton descriptor ne sera drop que une fois par ton programme ( Merci au borrowing ) même dans un context multi-thread.
Et sur EBADF? Rust oblige a checker les valeur de retour des fonctions, tu le spot bien avant le drop
La seul option valide ici serait de panic, mais c'est pas bon non plus.

Pour la partie sécurité, je ne pensais pas à du hacking mais plus a un truc du genre: tu programmes un logiciel pour les trains, même si ça crash et que tout est redondé, c'est un problème de sécurité des personnes physiquement. Et ne répondez pas, il faut des outils et des tests grrrrr

[rt15]

Ce que tu fais de l'erreur regarde le développeur : propagation, arrêt du programme, écriture d'un message dans un fichier de log ou dans la sortie d'erreur... Tu peux même l'ignorer si ça te chante.
D'après la doc, un close qui merde c'est aussi grave qu'un write qui merde.
Que par défaut Rust ne te protège pas du tout contre ça c'est très fâcheux pour un langage qui se présente comme sérieux et sûr.

[transgohan]

Créer une pointeur NULL et le déréférencé crash aussi.
Je trouve que ton argumentaire est un peu de mauvaise foi, même si, comme pour Pyramidev, je suis d'accord sur le fait que sacrifier les avantages du C (rapidité, mémoire, simplicité) en faveurs de plus de garde-fous, de contrôle (etc etc) est un must-have.
Néanmoins, quand on fait du C, on doit être rigoureux. Plus que dans d'autres langage.
Donc quand on manipule des pointeurs, on test si ceux-ci peuvent être NULL.

Et une fois le programme fini, on déroule les tests.
Et dans les tests, il doit au moins y avoir valgrind ou Dr Memory histoire de voir si les pointeurs ont été correctement géré.

C'est sûr, c'est plus long, c'est moins adapté à l'industrie actuel, mais c'est vitale, parce que sinon il suffit d'une erreur d'inattention pour faire un sigsev.
Mais bon, c'est pas comme si on pouvait pas faire des erreurs d'innatentions dans d'autres langages.

Je pense que je vais m'arrêter avec cette quote d'une excellente réflexion sur ce débat stérile où tout le monde veut avoir raison en ne prenant en compte qu'un segment de marché.

Pour anecdote je ne compte plus le nombre de nouvel embauché ou prestataire qui vient me dire que ça serait bien de remplacer toute notre base de code par du Rust parce que c'est le mieux qui se fait et que faut se mettre à jour. Bah je leur répond qu'il serait temps qu'ils pensent bas niveau et qu'ils me trouvent comment compiler du Rust pour des vieux processeurs comme du Motorola 68000 et qu'on en reparlera. J'attends toujours, depuis bizarrement ils font du C et ils ne s'en plaignent pas.
J'ai un peu l'impression de voir la même chose sur ce forum, tout le monde pense à son petit jardin sans penser au marché mondial qui comporte bien plus d'architectures que ce qu'ils peuvent imaginer.
On est en 2019 et on utilise encore bien plus de technologies des années 1980 que ce que vous pouvez imaginer.
Et c'est aussi pour cette raison, avec ce matériel éprouvé, que vous pouvez prendre le train, l'avion, la voiture, avec une sécurité qui me semble accru par rapport à des technologies sorties l'an passé.

Le C a encore de beaux jours devant lui, car tous les nouveaux langages ne prennent pas en compte les vieilles architectures.
Or en industrie on utilise souvent des équipements qui nécessitent 15 à 20 ans de qualification avant d'être utilisé.
Je ne serai pas étonné que le C ait encore une grosse part de marché dans 20 ans.

Oui il y a toujours mieux. Mais critiquer un langage parce que d'autres font mieux c'est un peu se voiler la face...

Pour la partie sécurité, je ne pensais pas à du hacking mais plus a un truc du genre: tu programmes un logiciel pour les trains, même si ça crash et que tout est redondé, c'est un problème de sécurité des personnes physiquement. Et ne répondez pas, il faut des outils et des tests grrrrr

Il suffit de sérieux... Et ce peut importe la technologie utilisée, qu'elle te prenne par la main ou non...
Même en Rust on peut faire des conneries qui peuvent tuer des vies.

Bref...
Dans 50ans on aura une autre technologie et un débat qui crachera sur le Rust peut être.

[Pyramidev]

Concernant Rust comme remplaçant du C, je vous propose de jeter un oeil sur les dernières lignes de ce fichier :
https://github.com/rust-lang/rust/bl...sys/unix/fd.rs

On est dans le coeur de Rust, et ce qu'il se passe lors de l'appel d'un destructeur d'un descripteur de fichier.
Rust ne vérifie pas la valeur de retour !
C'est une erreur de programmation.

L'utilisateur peut appeler manuellement std::fs::File::sync_all, mais je trouve dommage moi aussi qu'ignorer les erreurs de fermeture de fichier soit silencieux dans le code.

Bah je leur répond qu'il serait temps qu'ils pensent bas niveau et qu'ils me trouvent comment compiler du Rust pour des vieux processeurs comme du Motorola 68000 et qu'on en reparlera.

On n'a pas nié qu'il y avait des cas où il fallait faire du C car on n'avait pas de possibilité de prendre autre chose.

Dans 50ans on aura une autre technologie et un débat qui crachera sur le Rust peut être.

C'est fort possible.

[Kannagi]

Désolé de ne pas répondre au débat sur le C

Bluffé par ton travail Kannagi. Je ne sais pas par quel chemin t'es passé, librairies utilisées? Si il y en a...pour l'export des modèles de la PS2/DC par exemple. Quel compilateur assembleur utilises tu?
Si t'as un site qui parle des techniques utilisée dans tes projets ça m'intéresse par curiosité.

Alors tu vas être déçu , il n'ya aucun site (a ma connaissance) qui parle de ça.
Disons que j'ai de solides bagages en bas niveau donc communiquer avec le hard c'est mon dada

Alors sur ce genre de machine , il y'a aucun lib , si tu veux afficher un truc , tu demande au hardware de le faire
Cela ressemble pas mal à de l'embarqué , y'a pas mal de point commun entre codé sur une console de cette gen et de faire de l'embarqué sans OS.
En général j'utilise quelque lib fait par les amateurs (principalement la libc , le joypad et les lib du kernel).

Pour l'export des models 3D , j'ai utilisé un tools personnel que j'ai codé en C++ (avec la lib assimp) , assimp permet de lire la plupart des formats 3D existants , ensuite je le converti dans un format optimisé pour ces machines

Pour l'assembleur , je ne fais que de l'asm inline en C un exemple de multiplication de matrice sur PS2 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
 
void LMP3D_MatrixMultiply(float* dest,float* src1,float* src2)
{
  asm __volatile__(
    "lqc2            vf16,0x00(%1)\n"
    "lqc2            vf20,0x00(%2)\n"
 
    "lqc2            vf21,0x10(%2)\n"
    "lqc2            vf22,0x20(%2)\n"
    "lqc2            vf23,0x30(%2)\n"
 
    "lqc2            vf17,0x10(%1)\n"
    "lqc2            vf18,0x20(%1)\n"
    "lqc2            vf19,0x30(%1)\n"
 
    "vmulax          ACC,vf20,vf16\n"   //ACC = VF20 * VF16.x
    "vmadday         ACC,vf21,vf16\n"   //ACC = ACC + VF21 * VF16.y
    "vmaddaz         ACC,vf22,vf16\n"   //ACC = ACC + VF22 * VF16.z
    "vmaddw          vf16,vf23,vf16\n"  //VF16 = ACC + VF21 * VF16.w
 
    "vmulax          ACC,vf20,vf17\n"
    "vmadday         ACC,vf21,vf17\n"
    "vmaddaz         ACC,vf22,vf17\n"
    "vmaddw          vf17,vf23,vf17\n"
 
    "vmulax          ACC,vf20,vf18\n"
    "vmadday         ACC,vf21,vf18\n"
    "vmaddaz         ACC,vf22,vf18\n"
    "vmaddw          vf18,vf23,vf18\n"
 
    "vmulax          ACC,vf20,vf19\n"
    "vmadday         ACC,vf21,vf19\n"
    "vmaddaz         ACC,vf22,vf19\n"
    "vmaddw          vf19,vf23,vf19\n"
 
    "sqc2            vf16,0x00(%0)\n"
    "sqc2            vf17,0x10(%0)\n"
    "sqc2            vf18,0x20(%0)\n"
    "sqc2            vf19,0x30(%0)\n"
    : : "r"(dest), "r"(src1), "r"(src2) : "memory");
}

Apres sur PS2 , tu as un assembleur spécifique pour codé les VU0 et VU1 , mais ce sont des processeurs assez complexe , si tu veux un exemple de code asm que ça donne :
https://paste.ofcode.org/N669stSa3RSJuHR4C8YUF7

Mais la PS2 est un cas bien particulier niveau programmation , elle possède une architecture atypique sur certain point

Pour anecdote je ne compte plus le nombre de nouvel embauché ou prestataire qui vient me dire que ça serait bien de remplacer toute notre base de code par du Rust parce que c'est le mieux qui se fait et que faut se mettre à jour. Bah je leur répond qu'il serait temps qu'ils pensent bas niveau et qu'ils me trouvent comment compiler du Rust pour des vieux processeurs comme du Motorola 68000 et qu'on en reparlera. J'attends toujours, depuis bizarrement ils font du C et ils ne s'en plaignent pas.

Vous utilisez du M68000 ?
C'est un processeur que je connais bien , mais je suis étonné que le compilateur GCC pour le 68000 reste bien inférieur a ce qu'en peut faire en asm.
Par exemple pour mon SDK pour la Neo Geo (qui utilise le 68k) , mon code asm pour la décompression est 3 fois plus rapide que le code C (pourtant en -O3).
Du coup j'ai l'impression que GCC est vraiment performant que pour le x86 pour les autres architecture les compilateurs sont bon , mais j'ai l'impression que le code asm reste assez supérieur (si on à un bon niveau) :/
du coup ma question est vous utilisez le compilateur GCC pou un compilo spécifique ?

[Bktero]

Donc si je comprends bien si un développeur choisi C (que ce soit Linus Torvalds ou un autre développeur) pour développer son projet alors c'est une « interdiction sur le projet ». Par contre si un développeur choisi C++ pour développer son projet c'est un choix éclairé ? On est vraiment dans le grand n'importe quoi.

Oula non ! Je ne dis pas que choisir le C++ est un choix éclairé en soit. C'est juste que je pense que c'est un choix naturel mais d'autres peuvent choisir autrement. Après, oui quand Linus dit "pas de C++ dans Linux", il interdit le C++ sur son projet. On est au moins d'accord là-dessus ?

Pour information du trouveras une pléthore de projets écrits en pur langage C, même aujourd'hui, juste par choix des développeurs.

Je n'en doute pas. Mais si je devais vraiment >> troller << je dirais :



Tout ce que tu peux faire en C, tu peux le faire en C++ (même si les standards diffèrent sur certains comportement soi-disant communs). Alors pourquoi se priver ? Rien qu'en compilant avec un compilateur C++, tu as une vérification des types plus forte (un exemple limite anecdotique ici).

Pour un projet codé en C++ depuis un bon moment je compte 3 239 474 lignes de C

Choisir de passer en C++ pour le futur ne veut pas dire recoder l'existant en C ! Faut pas s'enflammer comme ça hein

Le seul fait qu'Orthodox C++ existe (mais également d'autres variantes) signifie que C++ ne convient pas à tout le monde. Et que même en 2019 ou 2020 on peut choisir de développer un projet en langage C, car un développeur est plus à l'aise avec ce langage, que le C est beaucoup plus simple que C++ et aussi beaucoup plus proche de la machine. Et non pas interdiction ou refus de monter en compétance.

Orthodox C++ ressemble plus à des coding rules pour moi. Touts les projets en ont. Même le mien qui utilise C++17 et lorgne déjà sur C++20 s'est interdit certaines features et utilise certaines autres avec modération. Pour ce qui est "proche de la machine", on fait de l'embarqué sur Cortex-M4, on a des contraintes importantes sur les tailles mémoires (RAM, ROM) et le temps CPU, on fait des calculs intensifs pour faire du pilotage moteur (avec les contraintes temps réel qui vont avec), on gère plein de matériel (EEPROM, flash, Bluetooth, capteurs)... et on est en C++17 dans tout ça

[transgohan]

Vous utilisez du M68000 ?
C'est un processeur que je connais bien , mais je suis étonné que le compilateur GCC pour le 68000 reste bien inférieur a ce qu'en peut faire en asm.
Par exemple pour mon SDK pour la Neo Geo (qui utilise le 68k) , mon code asm pour la décompression est 3 fois plus rapide que le code C (pourtant en -O3).
Du coup j'ai l'impression que GCC est vraiment performant que pour le x86 pour les autres architecture les compilateurs sont bon , mais j'ai l'impression que le code asm reste assez supérieur (si on à un bon niveau) :/
du coup ma question est vous utilisez le compilateur GCC pou un compilo spécifique ?

Historiquement nous sommes sur la chaîne de Microtec.
Nous avions tenté de passer sous GCC il y a 5 ans il me semble pour des questions de coût mais nous avons déchanté en tombant sur des bugs du compilateur (que je n'ai plus en tête mais ça nous a fait perdre pas mal de jours...).

Microtec racheté par Mentor Graphics, une filiale de Siemens si je ne m'abuse.
C'est propriétaire donc, et cela coûte un bras (7000$ la licence flottante si je ne m'abuse).
Sachant que la version la plus à jour il me semble est une versions pour Solaris.
Mais on utilise la version Linux sans problème vu depuis 2ans.

[Médinoc]

Ce code en C est correct. Ce que je voulais dire, c'est que si tu remplaces le code correct :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
config_s *userConfig = User_GetConfig(&userList[i]);
if (userConfig) {
	printf("The config content of this user is %d.\n", userConfig->content);
} else {
	printf("This user does not have any config.\n");
}

par le code incorrect :

Code C :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
config_s *userConfig = User_GetConfig(&userList[i]);
printf("The config content of this user is %d.\n", userConfig->content);

alors tu auras une erreur au runtime au lieu d'une erreur à la compilation.

Cet argument a sa pertinence, mais il ne soutient pas vraiment l'idée que la possibilité d'avoir des pointeurs nuls soit une "erreur à un milliard de dollars": Ça veut seulement dire que le problème est que tous les pointeurs aient la possibilité d'être nuls, alors qu'une distinction entre null/not-null inscrite directement dans le langage permettrait des diagnostiques au moment de la compilation (erreur qu'ils ont voulu corriger avec les toutes dernières versions de C#, si je me souviens bien).

Parce que les pointeurs nuls ont été créés pour une raison: On aura toujours besoin de la possibilité de dire "c'est optionnel".

[Pyramidev]

Ça veut seulement dire que le problème est que tous les pointeurs aient la possibilité d'être nuls, alors qu'une distinction entre null/not-null inscrite directement dans le langage permettrait des diagnostiques au moment de la compilation

C'est ce que j'ai dit dans mon premier message sur ce fil :

Le problème du langage C avec les pointeurs nuls est que, au niveau du typage, le langage C ne distingue pas les adresses obligatoires des adresses optionnelles

[CaptainDangeax]

Je code pour des microcontrolleurs 8 bits, Atmel ou Microchip.
Si l'ASM des Atmel 8051 reste relativement accessible, celui des PIC16 et PIC18 de Microchip est vraiment vraiment ardu. Alors, je code en C. Et pour éviter les problèmes de sécurité et d'allocation mémoire, je n'utilise pas de pointeur ni d'allocation mémoire dynamique.
Donc le C c'est sécure et c'est très performant. Même avec le compilateur C de microchip qui rajoute des lenteurs, en remplaçant les décalages de registres par des divisions ou des multiplications, ce qu'on peut corriger en ajoutant des pépites d'ASM à l'intérieur du langage C.

[Jamatronic]

Tout ce que tu peux faire en C, tu peux le faire en C++

En C je suis capable d'écrire des programmes qui peuvent se diagnostiquer tout seuls une éventuelle fuite de mémoire, qu'il est alors facile de corriger.
Je ne sais pas faire la même chose en C++.

[Pyramidev]

En C je suis capable d'écrire des programmes qui peuvent se diagnostiquer tout seuls une éventuelle fuite de mémoire, qu'il est alors facile de corriger.
Je ne sais pas faire la même chose en C++.

En C++, quand on maîtrise le RAII et quand on ne met pas partout des std::shared_ptr, il n'y a pas de fuites de mémoire.

Quoique, théoriquement, même avec du RAII, il peut y avoir l'équivalent d'une fuite de mémoire si la durée de vie d'un objet qui devrait être temporaire est lié à la durée de vie d'une variable globale ou d'un singleton. Ce type de fuite de mémoire est possible aussi dans des langages avec un ramasse-miettes.

Mais, en pratique, je n'ai pas encore vu ça. Toutes les fuites de mémoire que j'ai vues dans des programmes C++ venaient de code qui appelaient à la main new et delete au lieu d'utiliser le RAII, par exemple avec std::unique_pr.

[Bousk]

En C++ tu peux surcharger les allocations et suivre toutes celles que ton programme fait.
Tu peux donc à tout moment savoir quand une fuite mémoire est présente, mais en plus tracer où elle se produit.
Et vu que le C++ accepte une grande partie de la syntaxe C, ton programme C qui s'auto-diagnostique, tu as un bon 99% de chances qu'il compile tel quel en C++.