[C/C++]Dubbio sul funzionamento di malloc()

[sky_451]

Salve a tutti,
nel seguente codice ho allocato un array di 27 elementi short.
Com'è possibile che il for vada in crash solamente quando la i arriva ad essere uguale a 3728?
Per me era più logico che il programma si bloccasse non appena la i fosse arrivata ad essere uguale ad n. Sicuramente mi sbaglio.
Grazie per l'aiuto.

short *vettore;

int main()
{
     int n = 27;
     int i;

    vettore = (short *) malloc(sizeof(short) * n);

    for(){
        vettore[i] = 1;
    }

    return 0;
}

p.s. il file sorgente ha estensione .cpp e sto utilizzando visual studio 2008

[menphisx]

Quel for è completamente sbagliato.
Primo mancano due punti-e-virgola, Secondo cicla all'infinito.
Poi manca la free(), e vettore è globale, MALE !
E non controlli neanche il valore di ritorno della malloc.

Ecco la versione corretta:

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
     short *vettore = NULL;
     const int n = 27;
     int i = 0;

    if((vettore = (short *) malloc(sizeof(short) * n)) == NULL){

        puts("Memory failed");
        exit(EXIT_FAILURE);

    }

    for(; i < n; i++)
        vettore[i] = 1;

    free(vettore);
    vettore = NULL;

    return 0;
}

[oregon]

Il programma va in crash quando tenta di scrivere in indirizzi non allocati al processo.

Altrimenti, si "sporca" solamente della memoria appartenente comunque al processo, ma questo non causa un immediato crash.

Ma in tutto cio', la malloc non c'entra ...

[sky_451]

Per il for scritto male è stato un mio errore di scrittura, scusate:

for(i=0; i<999999; i++){
        vettore[i] = 1;
}

ecco io avevo provato con un for di questo tipo.
So che l'uso di variabili globali è orribile, ma per il progetto d'esame che sto facendo va più che bene e mi ha risparmiato un po' di tempo.
Il problema che ho nel programma originale è appunto quando vado ed eseguire la free che a runtime ritorna un'eccezione del tipo: HEAP CORRUPTION DETECTED.
Inizialmente ho pensato che l'errore venisse causato proprio dal fatto che la malloc allocasse più memoria del dovuto. Invece, mi sembra di aver capito da quello che ha detto oregon, che in realtà la memoria da i >= n e < di un tot non sia quella allocata per il vettore, ma per l'intero processo e finchè incasino quella non c'è nessun errore.
Allora non riesco a capire perchè la free genera l'eccezione. In più nello stesso programma eseguo la stessa identica operazione con altri vettori e quando eseguo la free tutto funziona.
Da cosa potrebbe dipendere?

[oregon]

Intanto e' diverso se hai compilato in modalita' debug (come mi pare di capire) o release.

Nel primo caso, le normali malloc e free della libreria sono sostituite da altre funzioni, appositamente scritte per effettuare alcuni controlli (come fa la free) circa eventuali scritture in aree fuori dalla zona allocata.

In modalita' release questi controlli non sono effettuati e gli eventuali errori di corruzione dell'heap potrebbero non essere rilevati (il comportamento e' indefinito, ovvero, casualmente potresti avere un errore oppure no ... secondo lo stato attuale dell'allocazione della memoria).

[sky_451]

Ho risolto il problema, però non mi spiego il perchè. Nel programma orginale il vettore verso veniva inizializzato attraverso una fscanf da file:

fscanf(fp, "%d", &verso[i]);

ora invece ho provato a utilizzare una variabile temporanea:

int temp;

fscanf(fp, "%d", &temp);
verso[i] = temp;

in questo modo la free finale non da problemi.

p.s. verso è sempre un array di short.

[oregon]

Ma cosa c'entra questo discorso con quello iniziale (la for oltre il 27 ???) ...

[sky_451]

La modalità è debug.

[oregon]

Scusa, ma non ci sto capendo molto ... ti ripeto, cosa c'entra con il problema del ciclo oltre il 27 ?

Cosa c'entra adesso la scanf?

Dov'e' la free?

[sky_451]

Il fatto è che io all'inizio pensavo che la free non andasse a buon fine perchè mi "sembrava" di allocare malamente la memoria. Però come mi hai fatto giustamente notare, questo non c'entra assolutamente nulla.