Newsgroup: it.comp.lang.c
Titolo: problema run time vettore di char allocato dinamicamente

Ciao,
Ho provato questo programma,
il compilatore non dà errore di sorta
ma a run-time ci sono problemi,
sapreste indicarmi che problemi ha il codice?
Grazie!
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
int main()
{
    char* s;
    s = (char*) malloc(128);
    s = "computer";
   free(s);
   system("pause");
   return 0;
}

 }
Quello che hai scritto č sostanzialmente equivalente a
int main() {
	free("computer");
}
che forse puoi immaginare perché sia sbagliato...
Per copiare le stringhe devi usare la funzione strcpy:
strcpy(s,"computer");  // invece che: s="computer";
E.

 }
int main()
{
	malloc(128);
	free("computer");
}
che è peggio!


a dirla tutta io avevo scritto il programma:
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
int main()
{
    char* s;
    s = (char*) malloc(128);
    s = "computer";
    printf("s = %s\n", s);
    free(s);
    system("pause");
    return 0;
}
Su Dev C++ compila correttamente e a run time produce il risultato
sperato, cioè
s = computer
Premere un tasto per continuare . . .
Su Visual studio invece a run time dà il seguente errore:
Windows ha generato un punto di interruzione in prova.exe.
Ciò può essere dovuto a un danneggiamento dell'heap che indica un bug
in prova.exe o in una qualunque delle DLL che ha caricato.
È anche possibile che l'utente abbia premuto F12 mentre prova.exe era
attivo.
Controllare la finestra di output per ulteriori informazioni
diagnostiche.

 int main() { free("computer"); }
geniale, si vede tutta che sei un matematico :)))))) non
mi è minimamente venuto in mente di spiegarla così!

    free(s);
e ti aspetti che la free funzioni !!!
se vuoi "giocare" con s devi scrivere nella locazione puntata da s
memset ( s , 0, 128 ); // pulizia dell'area allocata con la malloc
memcpy ( s, "computer", 8 ); // scrittura della "stringa"


 Windows ha generato un punto di interruzione in prova.exe.
Certo! stai rilasciando una memoria *mai* allocata in
modo dinamico...quella della stringa, che e' memoria *statica*!
B.

 il risultato sperato, cioè
Questa la trovo una cosa altamente preoccupante... Non so
ovviamente se si tratti di un'ottimizzazione spinta al
limite estremo ma se anche fosse possibile, non credo sia
desiderabile un compilatore che cerca di capire a questo
livello cosa l'utente volesse fare.
ciao!
Apx.

On 15 Dic, 11:09, Archeopteryx

Io sinceramente non vedo perche' il compilatore dovrebbe creare
problemi.
Il programma prende un puntatore, ci mette l'indirizzo di un pezzo di
memoria allocato dinamicamente, poi il programma dice di mettere
l'indirizzo di uns stringa statica nel puntatore.
poi viene stampato quello a cui il puntatore punta.
poi si cerca di liberare quello a cui il puntatore punta.
Al limite il problema e' nella free(), che potrebbe ritornare un
errore che non viene catchato. Ma non vedo perche' debba far crashare
il programma.
IMHO e' visual studio che fa troppo.
Ciao Jack

 IMHO e' visual studio che fa troppo.
Il problema e' che qui VS fa proprio il suo dovere! :)
Il comportamento di VS probabilmente si spiega cosi: dovendo
scegliere, hanno preferito un'implementazione piu' efficiente,
che non fa alcun controllo sull'origine del puntatore, invece di
una implementazione piu' lenta, che fa controlli che non
sono comunque richiesti dallo standard del linguaggio, secondo
cui free() puo' essere chiamata passandogli solo ed esclusivamente un
puntatore ottenuto da una malloc() o simili ed e' a cura del
programmatore, non della libreria o del compilatore, assicurarsi
che sia cosi'.
Su questo la filosofia del C e' diversa da altri linguaggi un po' piu' 
recenti! :)
ciao
Giacomo

 che sia cosi'.
IMHO è esattamente il contrario. VS si accorge che il puntatore non è 
valido e genera un'eccezione. Gcc invece non si accorge che il puntatore 
non è valido e prosegue l'esecuzione. Immagino che la scelta di VS si 
possa modificare nelle opzioni di compilazione, in questo caso la scelta 
è di dare maggiori informazioni per il debug a un piccolo costo di 
efficenza. Forse con le opzioni della "release" il controllo non 
verrebbe più fatto e il programma andrebbe un po' più veloce.
E.

 verrebbe piů fatto e il programma andrebbe un po' piů veloce.
Eh si! Hai ragione: ho letto troppo frettolosamente il messaggio 
originario! E' proprio come dici tu: in Debug mode VS fa dei controlli
in piu' rispetto al Release Mode per accorgersi di eventuali pasticci 
mentre gcc non lo fa.
Maledetta la mia fretta! :)
ciao
Giacomo