L'écriture de pointeur en dehors des limites après malloc () ne provoque l'erreur

Question

lorsque je tente le code ci-dessous il fonctionne très bien. Am quelque chose que je manque?

main()
{
    int *p;
    p=malloc(sizeof(int));
    printf("size of p=%d\n",sizeof(p));
    p[500]=999999;
    printf("p[0]=%d",p[500]);
    return 0;
}

Je l'ai essayé avec malloc (0 * sizeof (int)) ou quoi que ce soit, mais il fonctionne très bien. Le programme se bloque que lorsque je ne l'utilise pas du tout malloc. Donc, même si je 0 allouer la mémoire pour la p tableau, il stocke encore des valeurs correctement. Alors, pourquoi suis-je prendre la peine même avec malloc alors?

Answer 1

Il peut apparaît pour le travail bien, mais il est pas très sûr du tout. En écrivant des données en dehors du bloc de mémoire alloué vous écrasez des données que vous ne devriez pas. Ceci est l'une des plus grandes causes de segfaults et d'autres erreurs de mémoire, et ce que vous observez avec elle apparaissant au travail dans ce programme court est ce qui le rend si difficile à traquer la cause racine.

Lire cet article , en particulier la partie sur la corruption de mémoire, commencer à comprendre le problème.

Valgrind est un excellent outil pour analyser les erreurs de mémoire tels que celui que vous fournissez.

a fait un bon @ David commentaire. Comparer les résultats de l'exécution votre code à l'exécution le code suivant . Notez les derniers résultats dans une erreur d'exécution (avec à peu près pas de sortie utile!) Sur ideone.com (cliquez sur les liens), alors que l'ancien que vous avez vécu réussit.

main()
{
    int *p;
    p=malloc(sizeof(int));
    printf("size of p=%d\n",sizeof(p));
    p[500]=999999;
    printf("p[0]=%d",p[500]);
    p[500000]=42;
    printf("p[0]=%d",p[500000]);
    return 0;
}

Answer 2

Si vous n'allouez pas de mémoire, p a ordures en elle, donc écrit à elle échouera probablement. Une fois que vous avez fait un appel malloc valide, p pointe vers l'emplacement de mémoire valide et vous pouvez écrire. Vous écrasez mémoire que vous ne devriez pas écrire, mais personne ne va tenir votre main et vous dire à ce sujet. Si vous exécutez votre programme et une mémoire débogueur tel que valgrind, il vous dira. Bienvenue sur C.

Answer 3

Ecrire après la fin de votre mémoire est un comportement non défini ™, ce qui signifie que tout peut happen- y compris votre exploitation de programme si ce que vous venez de faire était parfaitement légal. La raison de votre programme en cours d'exécution comme si vous aviez fait malloc(501*sizeof(int)) sont complètement mise en œuvre spécifique, et peut en effet être spécifique à quoi que ce soit, y compris la phase de la lune.

Answer 4

En effet, P serait attribué une adresse peu importe la taille que vous utilisez avec malloc (). Bien que, avec une taille zéro, vous seriez référencez mémoire invalide que la mémoire n'a pas été affectée, mais il peut être dans un endroit qui ne causeraient pas plantage du programme, bien que le comportement sera indéfini.

Maintenant, si vous ne l'utilisez pas malloc (), il pointera vers un emplacement de garbaging et en essayant d'accès qui est susceptible de causer plantage du programme.

Answer 5

  

Je l'ai essayé avec malloc (0 * sizeof (int))

Selon C99 si la taille est passé à malloc est 0, un moteur d'exécution C retourne soit un pointeur NULL ou l'allocation se comporte comme si la demande était d'allocation non nul, sauf que le pointeur retourné ne doit pas être déréférencé. Il est donc mise en œuvre définie (par exemple, certaines implémentations renvoient un tampon de longueur nulle) et dans votre cas vous ne recevez pas un retour de pointeur NULL, mais vous utilisez un pointeur que vous ne devriez pas être using.If vous essayez dans un environnement d'exécution différent, vous pourrait obtenir un retour de pointeur NULL.

Answer 6

Lorsque vous appelez malloc () une petite partie de la mémoire est taillé dans une page plus grande pour vous.

    malloc(sizeof(int));

n'alloue pas en fait 4 octets sur une machine 32 bits (les pads allocateur jusqu'à une taille minimale) + taille des données méta tas utilisés pour suivre le morceau par sa durée de vie (morceaux sont placés dans des bacs en fonction de leur taille et marqué en cours d'utilisation ou libre par l'allocateur). hxxp: //en.wikipedia.org/wiki/Malloc ou plus précisément hxxp. //en.wikipedia.org/wiki/Malloc#dlmalloc_and_its_derivatives si vous testez cela sur Linux

écrit au-delà des limites de votre morceau ne signifie pas nécessairement que vous allez tomber en panne. P + 5000, vous n'êtes pas en train d'écrire en dehors des limites de la page allouée pour ce morceau initial de sorte que vous écrivez sur le plan technique à une adresse mappée valide. Bienvenue à la corruption de la mémoire. http://www.google.com/search?sourceid=chrome&ie = UTF-8 & q = tas + déversoirs

Answer 7

CheckPointer outil peut détecter cette erreur. Il sait que l'allocation de p était un morceau de 4 octets, et donc la cession est faite, il est en dehors de la zone pour laquelle p a été alloué. Il vous dira que le p [500] une erreur d'affectation.