6
votes

Allocation de mémoire dynamique du tableau entier

J'essaie de créer une matrice de taille 2, de manière dynamique, à l'aide de MALLOC. Voici mon code:

int *d = (int*)malloc(2 * sizeof(int));
d[0] = 4;
d[1] = 5;
d[2] = 8;
d[3] = 9;
d[4] = 7;
int i;

for (i = 0; i < 5; i++)
   printf("%d \n", d[i]);


1 commentaires

Votre comportement de code est indéfini moyen à une exécution différente, vous remarquerez peut-être un comportement différent, vous ne pouvez pas prédire à l'avance, votre programme peut être planté de temps en temps. Ce code est faux! peu fiable Malheureusement, C compilateur C ne signalent pas cela.


6 Réponses :


9
votes

Je me demande comment il a été capable d'attribuer plus de mémoire que celle que j'ai demandée.

Ce n'est pas. Vous appelez comportement indéfini . Un résultat possible * est que votre programme semble "travailler".


* sans doute, le pire.

0 commentaires

3
votes

Comme l'a dit Oli, c'est indéfini . Cela peut fonctionner, ce n'est peut-être pas. Mais la réalité est que même si cela pourrait fonctionner 99% du temps, il échouera au moins une fois, et vous obtiendrez un segfault de la lecture ou de la mémoire d'écriture que votre processus n'est pas censé utiliser, et vous vous retrouverez également avec des fuites de mémoire pratiquement non débutes.


0 commentaires

1
votes

C ne fait pas la vérification des limites. Vous piétinez sur la mémoire que votre programme ne possède pas.


0 commentaires

1
votes

Lorsque vous invoquez un comportement non défini, vous ne savez jamais ce qui pourrait arriver. Par exemple, lorsque j'ai dirigé le programme, j'ai reçu ce qui suit comme mon résultat:

4, 5, 8, 51, 1629501832


0 commentaires

3
votes

En plus de ce qui a été suggéré si je pouvais ajouter quelques notes supplémentaires.

Vous ne savez pas dans quel système d'exploitation vous exécutez, mais si vous êtes sous Linux à tout moment, vous ne devez pas fonctionner ou non via Valgrind code>. Dans mon cas, il a compilé un bon rapport sur toutes les erreurs avec votre code (y compris ne pas libérer la mémoire malloc code>). P>

J'ai eu trois ecrivage invalide de taille de taille 4 code> pour les trois extra écrit, vous faites à la mémoire. Il m'a également notifié de la mémoire invalide que vous lisez dans la boucle avec lecture invalide de taille 4 code> et enfin cela m'a donné des statistiques sur les fuites de votre code: P>

HEAP SUMMARY:
    in use at exit: 8 bytes in 1 blocks
  total heap usage: 1 allocs, 0 frees, 8 bytes allocated

LEAK SUMMARY:
   definitely lost: 8 bytes in 1 blocks


0 commentaires

1
votes

La raison pour laquelle cela semble fonctionner est parce que vous incrémentez votre pointeur à pointer vers de nouvelles taches en mémoire (que votre programme peut ou non être attribué à l'utilisation). Je suppose que vous déclarez cela sur la pile et c'est pourquoi votre comportement indéfini semble être "OK".

Je ne pense pas que vous comprenez la puissance d'un pointeur et de la syntaxe que vous avez utilisée. Remarquez que ce qui suit est équivalent: p>

int *d = ( int * )malloc( 2 * sizeof( int ) );

*( d + 0 ) = 4; // Observe you are accessing the memory location d points to.
*( d + 1 ) = 5; // Observe you are accessing the memory location d + 4 bytes (or 8 if 64-bit) points to...
*( d + 2 ) = 8; // ...
*( d + 3 ) = 9; // ...
*( d + 4 ) = 7; // Observe you are assigning a value to the memory location of d + 24 bytes (or 48 bytes if 64-bit).

for ( int i = 0; i < 5; i++) {
   printf( "%d \n", *( d + i ) );
}


0 commentaires