Je viens de vérifier avec ce code :

int main()
{
printf("Hello World");
int v=(int)0x9c;
if (v==NULL)
printf("0x9c est un pointeur NULL");
else
printf("0x9c n'est pas un pointeur NULL");


return 0;
}

Ca m'affiche "0x9c n'est pas un pointeur NULL". Vous pouvez tester le code ici : https://onlinegdb.com/oi9IbrDM5
Donc je dirais que vous avez tous les deux tord.

Mais dans l'exemple que vous donnez, il n'y a pas "if (v!=null)", pourtant c'est de ça dont parlait "Wogien" plus haut. Si vous parlez d'autre chose, je ne peux pas vous répondre puisqu'on parlait pas de ça au départ.

Vous dites ici "if (test!=null), mais dans le commentaire d'avant, vous faisiez référence au lien qui donnait ce code
: typedef struct {
int field1;
int field2;
} test_s;

int main()
{
test_s* test = NULL;

printf("Adresse de l'attribut field2 : %lx", (unsigned long int)&(test->field2));

return 0;
}
Or il n'y a pas de "if(test!=null)" dans ce code. Donc on ne parle de pas de la même chose.
Encore une fois, si vous testez :
int main()
{
printf("Hello World");
int v=(int)0x9c;
if (v==NULL)
printf("0x9c est un pointeur NULL");
else
printf("0x9c n'est pas un pointeur NULL");


return 0;
}

Ca m'affiche "0x9c n'est pas un pointeur NULL". Vous pouvez tester le code ici : https://onlinegdb.com/oi9IbrDM5
C'est de ça dont au parlait au début et uniquement de ça. NULL correspond à l'adresse 0, et if "(test!=null)" sera validé si test n'est pas égal à 0, et non pas si test n'est pas égal à 0x9a ce dont on parle dans l'article.

Heureusement que vous n'êtes pas désagréable !

Si c'est évident, pourquoi me contredire ? Ai-je dis autre chose ?

Non, cela n'est pas vrai, je n'ai rien modifié sur le site en ligne. Le copier/collé était le bon dès le départ, mais int * n'est simplement passé. Vous jugez vraiment n'importe comment sans savoir.

D'ailleurs, le (int*) est toujours présent dans mon commentaire initial lorsque je cherche à l'éditer, mais il ne s'affiche pas une fois validé. Preuve que je l'avais bien copier/coller.

D'autre part, vous proposez des tests pour éviter le problème dans le code en production, mais vous ne pouvez pas faire un try/catch à chaque fois que vous lisez une variable. Et même si vous le faites, il faut vous attendre à deux catégories de problèmes ; les exceptions (ouvrir un fichier qui n'existe pas), ou les erreurs (arriver à un état du programme qui n'aurait pas du arriver). A moins de considérer qu'une mauvaise adresse mémoire pointé par une variable soit un comportement normal, il s'agit au tout état de cause d'une erreur et non d'une exception. Dans ce cas, quand un programme génère une erreur, il faut laisser le programme planter et ne surtout pas continuer l'exécution pour éviter qu'un comportement improbable (et pire) ne se produise. Donc même si vous faites un try/catch, si ça ne doit pas arriver, il faut quand même terminer le programme. Le try/cath ne servirait dans cet exemple qu'à journaliser la trace de l'erreur et/ou à fermer correctement les verrous obtenus sur le système.

Le sens de mon premier commentaire était de dire que les langages C et C++ ne génèrent pas les mêmes exceptions en fonction de la configuration mémoire dans laquelle on se trouve à cause du laxisme des deux langages dans la gestion de la mémoire, ce qui pose problème quand on test le programme, que le test est validé dans un environnement et que l'erreur se produit quand même quand l'environnement et la configuration mémoire du programme changent, i.e. lorsque le programme passe en production. Ce type de problèmes intempestifs ne se produit pas dans d'autres langages de programmation, où la gestion de la mémoire est plus cadrée. Maintenant, je n'ai pas dit que c'est ceci qui s'est passé dans le cas de cet article d'où le "peut-être" dans mon premier commentaire.

Je ne réécrit pas l'histoire ! Je dis juste mon appréciation de c/c++ !

Bon, je vous ai lu à tête reposé. La dernière fois, j'avais une journée très chargées et j'ai lu beaucoup de choses en diagonale. Désolé, mais si vous commencez votre message par "il ne faut pas réécrire l'histoire", ça fait procès d'intention, et de mon point de vue, vous m'avez déjà jugé, je n'ai aucune chance que je me preniez pour votre égal. Donc, j'ai déjà plus trop envie de vous lire.

Puis vous avez commencé un historique des langages, et j'ai arrêté à ce moment de vous lire. Partir du principe que je ne comprend rien à ce que je raconte m'indiquait que vous jugiez sur les apparences. Alors certes, j'aurais du attendre un moment où j'avais plus de disponibilité pour vous lire, mais étant donné que vous ne donniez aucun crédit à ma façon d'aborder les choses, je ne voyais pas pourquoi je devais en faire plus que vous.

Pourtant après avoir relu tout vos commentaires, j'ai compris tout ce que vous aviez dit, même si j'estime que ça n'avait pas trop rapport avec mon commentaire initial, et comme je n'avais pas le temps de digresser, je n'ai pas vraiment compris pourquoi toutes ces digressions, et ces tons péremptoires que vous aviez avec moi. Le mal entendu naissait et grandissait de plus en plus.

Donc oui, un pointeur P de valeur nulle, qui pointe vers une structure à la position relative 4, aura l'adresse absolue 4, donc non égale à zéro. Je vous rassure, ce n'est pas une découverte pour moi. Le problème, c'est que comme c'est évident, il est impossible pour ma part de comprendre le malentendu avec des commentaires qui répondent à côté de mon commentaire initial avec des présomptions fortes sur ce que je sais ou pense dès le départ, et avec moi vous lit en diagonale n'ayant pas eu la patience d'attendre 1 jour pour répondre.

Très bien. Au moment de mon commentaire initial, je ne suis pas dans l'esprit de faire la différence entre le contexte du noyau et celui du programme, ou entre les adresses valides ou non. Je ne pense pas non plus "translation d'adresse". Mon commentaire initial n'en avait pas besoin, puisque je commentais le problème inhérent que pose le C, car la question n'est pas de savoir si on doit tester un pointeur NULL, mais pourquoi on arrive dans un état qui ne s'est pas produit pendant les tests. Le pointeur NULL n'a peut être rien à voir, et s'est peut être la résultante d'un bug plus en amont.

Dire qu'un noyau doit être stable, mais comment dire, vous pensez vraiment que quelqu'un pense que le noyau peut être bâclé dès lors que l'on comprend ne serait-ce qu'à minima ses fonctions ? Quiconque a déjà utilisé Windows Millenium sais ce que cela implique un noyau instable, qu'il soit informaticien, ou utilisateur de Word. J'ai l'impression que tous les utilisateurs de Windows Millenium étaient devenus superstitieux, tellement il était imprévisible. Pas besoin d'utiliser un argument d'autorité pour le savoir.

Cela étant dit, lorsque je dis qu'un programme qui arrive dans un état incohérent doit tout arrêter, vous dites en retour que l'on ne peut se permettre d'en faire autant avec le noyau en tant que dev, avec en creux l'idée qu'il faille continuer coûte que coûte, ce qui n'est pas ce qu'a choisi de faire le noyau de Windows. C'est votre appréciation, mais si ne vous faites pas planter un noyau sans savoir si c'est bien raisonnable, comment être sûr que ce ne sera pas pire ? Ce qui s'applique pour un programme, s'applique aussi pour le noyau.

Si l'on se place du point de vu d'un programme, l'objectif principal est que ce dernier ne plante pas et remplisse ses rôles. Si à un moment un problème se pose et que cette éventualité avait été anticipée, on peut alors prévoir plusieurs stratégies pour fonctionner en mode dégradé. On peut déléguer la tâche à un système de secondaire, on peut considérer une autre option, on peut simplement désactiver une fonctionnalité, on peut considérer que le problème n'est pas si important et qu'il suffit juste de faire remonter l'information dans un rapport, on peut appliquer un autre algorithme contournant le problème en le résolvant d'une autre façon, on peut développer un système avec une tolérance à la panne, etc.

Mais si le problème n'avait pas été anticipé, et s'il arrive quand même alors qu'il ne devrait pas arriver, c'est à dire au moment d'une assertion qui vérifie un pointeur non NULL par exemple, alors il faut faire planter le programme.

Imaginez un outil de contrôle aérien qui arrive dans un état mémoire théoriquement impossible alors qu'il a été testé mille fois, de manière empirique et par un système de preuve. Vaut-il mieux tout faire planter, ou continuer ?
- Si vous continuez, vos tests unitaires ne détecterons rien. Peut être aurez vous un rapport de généré, mais si vous oubliez le lire à temps, votre programme aura quand même poursuivi son excécution.
- Vous pouvez aussi ne pas avoir la même stratégie pendant les tests ou en production, mais dans ce cas, vos tests ne sont pas tout à fait valides car il ne testent pas la même chose.
- Si vous faites tout planter, et que cela arrive pendant les tests, vous corrigez vos tests. Mais si vous poursuivez l'exécution du programme en production sans savoir si cela est bien raisonnable, et alors que vous êtes sûr que cela ne devrait pas arriver (assertion), vous prenez le risque pour le dire vite d'afficher à l'écran des avions à une mauvaise position.
- Si vous faites tout planter et que cela arrive en production, vous avertissez les contrôleurs aérien que le système n'est plus fiable, et qu'il faut qu'ils se débrouillent autrement. Faut-il tout faire pour en arriver là ? Non, car un oui serait trop évident -> que voulez-vous que je vous dise d'autre ? Tout ceci est banal, et je suis sûr que je ne vous apprend rien.

Maintenant, la question soulevée au départ est, pourquoi un programme qui ne plante pas pendant les tests peut finir par planter en production avec le C ? Etant donné que le C permet de faire n'importe quoi avec la mémoire (oui oui), il suffit que la configuration mémoire soit différente au moment de l'exécution pour que le comportement du programme soit différent.

Car justement, le langage C ne vérifie pas si un accès mémoire est autorisé ou non. Tant que la zone pointée ne déborde pas de l'espace d'adressage du processus, le noyau ne dit rien (enfin le processeur, ça serait trop lent si le noyau testait chaque accès mémoire sans accélération processeur). Si vous faites un dépassement mémoire, ou si vous lisez un pointeur non égal à 0, parfois le programme plante, parfois c'est le noyau qui le fait planter, parfois il ne plante pas.

Rien que de changer les options de compilation fera donner un comportement différent au programme avec le même bug, voir cela fera virtuellement disparaître le bug, le programme n'ayant pas planté.

On peut même avoir un pointeur non initialisé qui vaut une valeur aléatoire au moment des tests, car une variable non initialisée prend par défaut la valeur de son état mémoire au moment de son allocation, probablement non NULL. Donc si cette valeur par défaut correspond à une valeur acceptable de l'espace d'adressage du programme, le processus ne plante pas. Si vous relancez plusieurs fois le test sur la même machine, en relançant plusieurs fois le même programme, la configuration mémoire de l'ordinateur de test n'ayant pas changé, le bug n’apparaît jamais, le pointeur n'est jamais à NULL.

Pendant la prod, disons pour des raisons d'options de compilation différentes, le pointeur non initialisé aura la valeur par défaut à zéro, et le programme plante à se moment, là où il n'avait pas planté pendant les tests. Voilà un scénario possible. Mais il peut y en avoir d'autres.

Est-ce que c'est cela qui s'est passé ici ? Je ne sais pas, je ne faisais qu'émettre une hypothèse.

Ce qui nous amène au fond du sujet, puisque vous avez quand même répondu à mon commentaire initial à un moment, c'est à dire dans le commentaire auquel je répond présentement. Vous dites que C est un langage à remettre dans son contexte. Très bien, mais là encore, vous enfoncez une porte ouverte. Le problème n'est pas celui là, ni l'histoire du C, mais plutôt que faisons nous en 2024 avec un tel langage ?

Vous dites en creux qu'un OS ne peut se passer d'un tel langage qui permet tant de liberté. Peut être avez-vous raison, personnellement, n'étant pas dev sys, je me contente d'observer que personne n'a envie de redévelopper plusieurs millions de ligne de code d'un noyau dans un autre langage, d'autant que beaucoup de dev sys développent en C. Est-ce que les deux raisons qui font que le C soit toujours aussi populaire ne sont pas les suivantes :
1. il n'y a pas assez de monde dans les dev sys qui maîtrisent un autre langage que le C
2. il est très démotivant de redévelopper tout un noyau dans un autre langage dont on ne sais même pas s'il est plus mature que le C .

Mais comme ici, il s'agissait que d'un (parait-il faux) pilote, peut être qu'en fait si, on peut progressivement développer dans un autre langage, qui plante dès qu'un accès mémoire n'est pas licite à l'intérieur même du processus, et non plusieurs centaines de lignes plus loin, et non "jamais jusqu'au jour où on le met en prod". Peut être qu'à la périphérie du noyau et dans les couches du dessus, il n'est plus nécessaire de développer dans un langage devenu pour moi bien trop vieux. C'est bien là mon droit d'émettre une opinion. Personne ne vous oblige d'être d'accord. Mais ne croyez pas qu'une seule opinion doit survivre. Ce n'est pas Highlander !

Je pense franchement qu'on aurait pu éviter ces digressions et cette perte de temps, car je soupçonne que dès le départ, que vous comprenez ce type de position.

Mais la question n'est pas de faire un catch, mais quoi faire du catch ? Si vous décider de poursuivre l'exécution alors que l'état du programme est incohérent, vous n'aurez rien résolu du problème initial et vous déplacez le problème ailleurs. S'il y a un écran bleu sous Windows, ce n'est pas parce que le noyau fonctionne mal (ou pas forcément), mais parce que le noyau est arrivé dans un état incohérent où il ne peut poursuivre son exécution sans potentiellement aggraver le problème. Un catch pour empêcher l'écran bleu ne changerait rien au fait que cela n'aurait pas du arriver dans le sens où le bug n'a pas été anticipé (sinon, il n'y aura pas de bug en fait).

Ce qui peut arriver à l'échelle du noyau peut aussi arriver à l'échelle d'un programme. Faire un catch de quelque chose d'incohérent dans le contexte, ne changera rien au fait que cela n'aurait pas du arriver. Et donc, dans ces conditions, il vaut mieux que tout plante plutôt que continuer l'exécution avec un cas non prévu. C'est tout ce que j'ai essayé de dire, et c'est pas la peine de me prendre de haut en entrant dans les détails technique du C pour noyer le poisson dans l'eau. Ce que je dis est une banalité. Votre façon de me rabaisser est intolérable.

Si le bug est prévisible, ce n'est pas vraiment un bug, vu que vous qu'en l'anticipant, une correction s'impose d'elle même. A partir du moment où vous n'avez pas prévu le bug, il se produira, ce qui s'est produit ici. Maintenant, oui, si le correctif consiste à dire qu'on peut passer au fichier sys suivant, c'est pas grave, OK. Mais les bugs se produiront toujours parceque vous n'avez pas anticiper un problème, jamais autrement, à moins de travailler dans l'objectif de saboter le projet (ce qui peut être une piste cela dit). On peut toujours dire après coup, on aurait pu faire ceci ou cela, mais bon, résoudre le problème à postériori ne résou pas le problème à priori. Impossible de remonter dans le temps.

Donc soit vous décidez à priori que certains problèmes peuvent se poser et que vous pouvez ignorer le chargement fichier sys à priori en toute conscience, soit vous décidez à priori qu'aucun problème ne devrait se poser, car au moment où vous écrirez le code, vous considérerez que le problème que vous envisagez est impossible (à tord ou à raison), et que s'il se produit quand même, c'est que au moment où vous y pensez, vous ne savez pas pourquoi cela se produit. Soit vous tolérez l'erreur sans trop savoir ce que ça va donner (et éventuellement ce que cela va empirer), soit vous faite tout planter, en disant qu'il vaut mieux préserver l'intégrité du système, et notamment l'intégrité des données qu'il ne faut pas corrompre. Si le noyau arrive par exemple à un état non anticipé, est-ce qu'il vaut mieux générer un écran bleu ou continuer au risque de bousier le système de fichier ? Par exemple, et petite digression, j'ai entendu du dire que le noyau Linux était tellement stable qui ne générais pas de kernel panic même avec une mémoire instable. Personnellement, cela m'est déjà arrivé d'avoir une mémoire instable, le noyau n'a pas planté, et pourtant mon ordinateur faisait n'importe quoi (j'ai mis du temps à comprendre que c'était la mémoire le problème, enfin 2h). J'estime avoir eu de la chance que ça n'ait pas eu plus de conséquences sur mon système de fichiers. J'aurais préféré un kernel panic. Maintenant, dans le cas de cet article, je ne sais pas trier ce que peut être toléré comme erreur de ce qui ne peut pas l'être.

Ce que je dis en revanche, c'est que les bugs arrivent quelque soit les précautions prises. Donc par définition, si on n'anticipe pas un bug et son sens, c'est qu'on ne sais pas s'il faut faire tout planter, ou si on peut tolérer l'erreur. Pour tester un programme, on doit faire des tests, et mon propos initial supposait que des tests sur Crowdstrike avait bien été effectués avant la mise en production. Je me suis alors demandé comment des tests peuvent passer sur une machine de test et pas sur une machine en production ? Du fait qu'un programme C ne fait pas toujours planter un programme à cause d'un mauvais accès mémoire, seul le noyau fait planter le programme s'il se rend compte que l'accès porte sur un espace mémoire non autorisé. Mais si l'accès mémoire est autorisé au moment du test, bien qu'incohérent, le noyau n'arrête rien, et le programme C n'arrête rien non plus, ce qui n'aurait pas été le cas d'autres langages (Pour les langages système, on peut citer Rust). Cela peut être une hypothèse (entre autres) de pourquoi le bug a passé les tests : l'environnement mémoire n'était pas le même, et dans un cas, le noyau ne fait pas planter le programme, dans l'autre il faitt planter le programme (et lui même), et pas de chance, ça tombe en prod. Ben ça, ça arrive typiquement avec C/C++.

Donc au final, un langage moins laxiste sur la gestion de la mémoire, si les hypothèses de départ sont les bonnes, aurait peut être permis d'éviter le problème, car le dit programme aurait planté dès la phase de test.
En disant cela je comprend qu'on ne peut pas se permettre de tout recoder en Rust, mais tout de même, je n'ai jamais trouvé bien pratique cette façon d'accepter n'importe quoi en C en matière de gestion de mémoire, en pariant sur le fait qu'un⋅e développeur⋅e doit être parfait (impossible !), et que cela ne devrait jamais arriver.

Si l'exception pouvait être catché, très bien, il aurait fallu le faire. Je n'ai pas de problème avec l'idée et ne dit pas le contraire. Sauf que là, c'est une exception non prévue, puisque de fait, elle n'était pas attendue ni anticipée, sans doute à tord. Je dis juste que vous ne pouvez pas catcher toutes les exceptions sans réfléchir à chaque fois pourquoi vous le faites.

Je vais partir du cas général, pour arriver au contexte du bug cité plus haut.

Admettons que vous faites "a=1/2". Vous ne pouvez pas faire un catch d'une exception générique de cette opération, en disant j'attrape tout. Si vous avez une division par zéro, c'est incohérent car elle ne devrait pas arriver, donc autant tout faire tout planter (la mémoire peut être instable ou que sais-je). Si vous continuez l'exécution, vous arrivez de toute façon dans un état incohérent.

Autre exemple, si vous n'avez plus assez d'espace mémoire et avez une exception de ce type, vous pouvez essayer de catcher l'exception, mais si vous le faites, vous devez savoir comment vous en sortir sachant que vous n'avez pas assez de mémoire. Et peut être qu'il n'y a pas de bonne façon de s'en sortir ici. Donc en faisant un catch de cela sans y réfléchir, vous risquez de générer une boucle infinie d'exceptions indiquant qu'il n'y a pas assez de mémoire et comme vous catchez l'exception sans prendre des mesures adéquates, ça ne s'arrête jamais, ce qui sans doute n'a pas fait planter le noyau, mais je ne sais pas trop quel serait son état si un de ses drivers tourne à l'infini.

Mais c'est valable en général pour un algorithme. Si votre algorithme arrive dans état complètement illogique (enfin à priori), je dis qu'il faut tout faire planter, ne serait-ce que pour s'en rendre compte pendant les tests. C'est le principe des assertions.

Donc ici, pour revenir au contexte du "sensor"/driver qui ne s'en sortait pas à cause d'un accès mémoire invalide, vous pouvez faire un catch du tout et n'importe quoi, mais si vous faites ça, vous devez vous assurer que ce n'est pas une fausse bonne idée. Alors bien sûr, dans le contexte du noyau, sans doute aurait-il fallu simplement ignorer le chargement du drivers, émettre un rapport comme vous le dite, et passer à autre chose. Mais du coup, vous faites un catch en conscience de ce que vous faites, et vous acceptez de faire sauter un "sensor"/drivers lors du chargement de tous les drivers. Je n'ai pas du tout de problème avec l'idée. Mais au moment où prenez cette décision, vous acceptez que des drivers peuvent être manquants, et devez en tenir dans toute votre architecture, sinon, cela pourrait planter ailleurs, et ainsi de suite. Donc oui, avoir une tolérance à la panne, et faire simplement remonter un rapport aurait sans aucun doute été la bonne solution ici, mais ça ne s'improvise pas, il faut peut être en tenir compte ailleurs dans le reste de l'architecture.

Si vous faites des catchs partout sans prendre la mesure de ce vous êtes en train de faire, cela risque in fine de quand même planter mais beaucoup plus loin dans le programme, et là bon courage pour remonter le bug, surtout si vous avez pleins de rapports qui été pondus pendant 2 jours avant que ça ne plante quand même (je ne dis pas que c'est ce qui se serait passé ici, je n'en sais rien). D'autre part, comme c'est dans l'espace noyau, cela pourrait avoir des conséquences délétères non prévues si vous ne l'avez pas bien encadré. Vous évoquez les problèmes économiques, mais là, on parle d'une machine immobilisée par un BSOD. Étant donné qu'on est dans l'espace noyau, imaginez qu'en catchant tout et n'importe quoi, le noyau se mette à faire tout et n'importe quoi en dézinguant le système de fichier. Là, c'est carrément la cohérence des données du système de fichier que vous pouvez flinguer. Je ne sais pas si on peu en arriver là, et si les gardes fou du noyau sont suffisants, mais je veux dire que dans un contexte économique, il y a pire qu'un BSOD.

Mais encore une fois, dans le contexte de ce bug, il était sans doute possible d'accepter une tolérance à la panne, mais cette tolérance doit tout de même être anticipée et encadrée, ce qui n'a pas été le cas ici et c'est bien dommage. Mais ce n'est pas une décision qu'il faut prendre de manière légère et aveugle comme une règle générale (en tout cas pas pour moi).

Donc je ne dis pas "Donc si je comprend bien, comme il n'est pas possible de prévenir de tous les bugs, évitons d'essayer de prévenir de quelque bug que ce soit...", je dis "essayez de prévenir tous les bugs, y compris ceux que vous comprenez pas à l'avance, acceptez la tolérance à la panne, mais si un bug ou une panne non anticipée arrive quand même alors que vous ne l'avez pas prévu ni encadré, je ne crois pas qu'il faille faire un catch aveugle sans en mesurer les conséquences, d'autant qu'à force de faire ça, vous prenez le risque de rendre un bug silencieux lors des tests, et rendre vos remontées de bug plus pénibles et fastidieuses.