Bonjour tout le monde !

Comme vous le savez, le C++ ne vérifie pas le dépassement des bornes des tableaux lorsqu'on tente d'accéder à une case d'un tableau. En d'autres termes, on peut accéder à de la mémoire à laquelle on est pas censé accéder en tapant tableau[99] dans un tableau de taille 70 par exemple.

De ce fait, je me posais une question : Est-ce que cela veut dire qu'un programme C++ mal codé peut corrompre par inadvertance des fichiers sur une machine ? En gros, est-ce qu'accéder à des adresses mémoires qu'on ne connaît pas est si dangereux que ça ?

Merci d'avance !

-
Edité par Autechre 2 juin 2021 à 22:49:48

Salut !

Non, rassure toi, il n'y a pas de "débordements" vers d'autres fichiers comme on pourrait l'avoir sur des tableaux en C.

Tout simplement parce qu'on n'adresse pas directement la mémoire du disque dur, on fait des requêtes (en C++ via ifstream ou ofstream) et que ces classes sont sécures, et appellent elles mêmes des requêtes système qui vérifient la validité de ce que tu demandes, et ne bousillent pas les fichiers.

Tu ne crains rien à manipuler des fichiers (enfin tu ne crains rien pour les autres fichiers qui n'ont rien à voir)

Attention cependant, il existe aussi des fonctions pour effacer des fichiers. Donc on peut faire des conneries, mais de manière explicite. 

-
Edité par Fvirtman 2 juin 2021 à 23:03:34

Bonjour,

Je dirais plutôt que c'est extrêmement peu probable.
Un accès en mémoire à une position non désirée peut :
- s'il tombe dans une zone interdite, on a une "segmentation fault" et un arrêt immédiat du programme.
- s'il tombe dans une zone pas vraiment utilisée, on aura l'impression que tout est ok. On pourrait écrire et relire la bonne valeur. C'est le cas le plus gênant car on ne voit pas le bug.
- s'il tombe dans une zone utilisée, l'écriture va modifier quelque chose.
-- souvent ça provoque un plantage ou une erreur ailleurs et plus tard. Ça ça donne un beug chiant à corriger.
-- ça peut alors tomber sur des données sensibles amenant l'application a des actions incohérentes. Supposons qu'à cet instant un fichier soit ouvert quelque part dans l'application, ça peut altérer les tables et amener une commande d'écriture fichier non voulue. Est-ce que ça peut écrire dans un fichier ouvert en lecture? Est-ce que ça peut perturber le gestionnaire de fichier pour qu'il en plus se trompe de fichier? Vu l'ensemble des contrôles du système comme l'a indiqué Fvirtman c'est extrêmement peu plausible. Il faudrait surement que le driver de fichier soit lui-aussi bogué mais ...

Si j'ai donné l'impression que c'est possible, on peut aussi penser à un autre cas. As-tu entendu parler des rayons cosmiques? Ce sont des rayons d'ultra haute énergie qui pour la plupart ne franchissent pas la ceinture de Van Hallen, mais certains arrivent à traverser la terre! Donc parfois ils peuvent percuter le noyau d'un atome au mauvais endroit au mauvais moment. C'est très rare et en plus les conséquences sont souvent mineures, mais si ça tombe sur le processeur qui exécute ton programme, ça peut modifier un bit qui va alors altérer une instruction ou une mémoire avec les conséquences vu avant. 

Je comparerais les 2 cas en disant qu'il sont aussi improbables, si on s'intéresse à tous les programmes du monde peut être que ça arrivera, peut-être que c'est déjà arrivé, peut-être que l'humanité aura disparu avant même que ça n'arrive!!
Autrement dit : c'est pas un bug c'est à cause d'un rayon cosmique est une mauvaise excuse à moins de travailler dans un logiciel extra-planétaire!

Rassure-toi tu ne perdras pas de fichier a cause de tes bugs.

Toutes les sondes, landers, rovers, etc ont subisces bugs de rayon cosmique, et c'est normal (blindage = coût astronomique ).

>peut-être que c'est déjà arrivé

Et C'EST déjà arrivé, et dans un cas assez épineux (c''est pour cela que ce n'est pas passé inaperçu avec l’excuse habituelle du "c'est un bug informatique parce que ça été code par un stagiaire") : le premier vote en Belgique qui prenait en compte le vote électronique. L'un des bits d'un compteur de vote était passé de 0 à 1 grâce à un rayon cosmique "farceur" : décalage d'un nombre "puissance de 2" entre différents compteurs et maintenant c'est renfort de la redondance et blindage anti-rayon pour tous les calculateurs. (c'est quand même bien fragile la "démocratie", )

Bien sûr, il y a vraisemblablement plein d'autres cas non détectés, et l'utilisation du Big Data fait que la probabilité doit frôler le 100% par jour.

P.S.: sinon pas besoin de chercher une rayon farceur pour avoir ce type de problème, un simple fichier mappé en mémoire et un bug dans la mémoire arrive automatiquement dans le fichier.

-
Edité par bacelar 4 juin 2021 à 15:11:16

Alors, pour les serveurs on utilise généralement de la mémoire ECC pour éviter ce genre de problème, par contre si ça se produit dans le CPU ou n'importe quel contrôleur ça ne change rien mais c'est statistiquement moins probable.