Newsgroup: it.comp.programmare.win32
Titolo: Visual C++ e stringhe

Salve a tutti!
Ho ua domanda molto sciocca ma che mi sta facendo scervellare da
questa mattina.
In un semplicissimo programma, nella WinProc ho messo qualcosa di
simile:
case WM_LBUTTONDOWN:
       {
         PTCHAR buff;
         PTCHAR mom="Ciao!";
 
         buff=(char *)malloc(sizeof(char));
 
         sprintf(buff, "La lunghezza di %s è %d.", mom, strlen(mom));
         MessageBox(0, (LPCSTR)buff, "Test", 0);
 
         return(0);
       }
Non riesco a capire come mai il programma regge il primo click del
mouse per poi schiantarsi al secondo. Se per caso dopo la MessageBox
(o TextOut) metto le free per deallocare i due puntatori. al secondo
click mi compare un messaggio di debug: "Damage: after normal block
#39".
Pero'... Se nella malloc uso sizeof(char)*dimensione_della_stringa
tutto funziona.
Ho lavorato per un paio d'anni con il gcc sotto Linux e questo
problema non mi e' mai capitato.
Infatti:
#include <stdio.h>
#include <stdlib.h>
int main(void)
{
	char *i;
	i=(char *)malloc(sizeof(char));
	sprintf(i, "Ciao");
	printf("%s\n", i);
	return(0);
}
Funziona egregiamente sia sotto Linux che sotto Win (compilato come
progetto per DOS con Visual C++ .NET).
A questo punto mi viene da pensare che c'e' qualcosa a livello di
compilazione nei progetti Win32 ma onestamente non capisco cosa...
Vi ringrazio in anticipo!

        }
Povero Windows....mamma mia....
E ti meravigli che ti salti?
Kiuhnm

 E ti meravigli che ti salti?
No, sospetto che c'e' qualcosa sotto ma onestamente non capisco cosa...
-- 
       Tremal-Naik -- Ghouls Emperor -- GnuPGid: 0xF093D6AD
E.A. Poe Klingon Translation Project: 
http://www.cs.unibo.it/~mbenini
List of my abandonware games: 
http://www.cs.unibo.it/~mbenini/abandon
    My miniatures page: 
http://www.cs.unibo.it/~mbenini/miniature


incolpiamo sempre noi stessi.
Maurus

No, sospetto che c'e' qualcosa sotto ma onestamente non capisco cosa...
Ho anche provato ad eliminare i vari cast (alcune righe le ho prese
dal Petzold) nella MessageBox ma nulla da fare...
Ehm... Ho appena notato che nella MessageBox c'e' uno 0 dove ci vuole
l'handler. Quindi ora ho: MessageBox(hwnd, (LPCSTR)buff, "Test", 0);
Ma i problemi rimangono...

codice, di solito i e' un indice temporaneo
Ragione anche qui ma in questo caso avevo scritto queste tre righe in
fretta e furia.
Grazie molte per il chiarimento!!

         return(0);
Allochi spazio per un solo carattere e poi ce ne copi una trentina?
Dovrai usare:
buff=(char *)malloc((30 + strlen(mom)) * sizeof(char));
.
.
.
free(buff);
Kiuhnm

 problema non mi e' mai capitato.
Caspita! Deve essere alto il livello di professionalità dei prog. 
Linux... 8-PPPPPPP
-- 
Luc.

 Linux... 8-PPPPPPP
 
Touche'! :) Ammetto pero' che tale sintassi l'ho usata pochissime volte
(sperando ovviamente di non aver lasciato correre altri errori).
Comunque sono andato a vedere i miei vecchi appunti di programmazione e
debbo dire che il professore ha commesso il mio stesso errore durante la
spiegazione.
Mi sa che in settimana andro' a comprarmi il K&R!
Ne approfitto per ringraziarvi...


 	printf("%s\n", i);
[CUT]
??!?!? :)
...che fa il gcc, "prevede il futuro" :-) e alloca altra memoria, anche 
se tu gli chiedi _solo un char_ (sizeof(char)) ?!? :)
...e' stranissimo che _in un paio d'anni_ il bug non sia mia uscito 
fuori allo scoperto?!?!!!?
ciao!
coden

fuori allo scoperto?!?!!!?
C'e' da dire che non ho praticamente mai usato questa soluzione. Di
solito uso char stringa[100] e vivo felice. Probabilmente in
condizioni di pericolo il gcc capisce l'errore e alloca un certo
spazio.


Non credo proprio: sarebbe scorretto da parte sua.
Semplicemente avrai sovrascritto dati non importanti per il programma.
Kiuhnm

 spazio.
...mi auguro proprio di _no_ ! sarebbe un _pessimo_ compilatore se lo 
facesse :)

 uscito fuori allo scoperto?!?!!!?
ovviamente è impossibile allocare un solo byte alla volta. Si alloca 
una pagina alla volta, cioè 4 KB sui PC, malloc() si limita a vedere se 
le pagine già allocate bastano, sennò ne alloca un'altra. Hai appena 
assistito alla nascita di un bug di heap overflow
-- 
 < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
     Don't stand, REACT!      version 0.0.20. C, C++ and ASM developers
                              and beta testers are welcome!