[C] quesito credo proprio banale ma che non riesco a risolvere

[fusionalfa]

Originariamente inviato da Ghiozzo
ma netbeans è anche per C? sapevo che era per Ruby...

sisi anche c - java....

[simo_85]

Originariamente inviato da Ushas
Non so se ti può aiutare, magari ti "illumina" ( ) ma ho notato che se cambi la condizione di terminazione del for, per esempio metti k<=35, quello che viene fuori è una sfilza di 0 più lunga e invece che "Testodiprova" ci viene scritto solo "diprova".

Chiaro, stringa è dichiarato prima di prova quindi quest'ultimo viene allocato prima di stringa, di conseguenza dopo i 30 bytes in memoria ci sarà l'indirizzo di stringa, e tu con quel k <= 35 stai andando a sovrascrivere appunto l'array stringa..

[simo_85]

Il problema comunque è dato dal fatto che non viene dato a nessun elemento di "prova" il valore NUL, quindi è normale che la printf stampa anche la stringa successiva ("stringa", che è allocata dopo "prova). Non sà dove finisce "prova"...
Puoi risolvere così:
Correzzione

for(i = 0; i <= 30; i++)
{
   prova[i] = '0';
		
   if(i == 30)
      prova[i] = '\0';
}

[Salvy95]

#include <iostream>

using namespace std;
int main()
{
char stringa[30]="testo di prova\0";
char prova[31];
int k;
for(k=0;k<=29;k++){
prova[k]='0';
}
prova[k+1]='\0';
printf("risultato stringa %s",prova);
 } 

Se non chiudi una stringa, alcuni compilatori continuano a scriverci sopra

Al posto dei ? inserisci \0

[MItaly]

Originariamente inviato da Salvy95
Se non chiudi una stringa, alcuni compilatori continuano a scriverci sopra

Il compilatore non c'entra niente, è il codice che è sbagliato, se la stringa non è NUL-terminata è normalissimo che la printf vada avanti a cercare il NUL prima di fermarsi.
Inoltre le stringhe literal sono NUL-terminate automaticamente, non c'è bisogno di aggiungere il \0 anche in fondo a "testo di prova".

@simo_85: occhio, prova è un array di 30 char e stai scrivendo sul 31° => buffer overflow.

[Salvy95]

E allora mi spieghi perchè sul dev c++ da problemi e sul code::blocks non da problemi?
I compilatori spesso intervengono ad eliminare eventuali errori al codice

[simo_85]

Originariamente inviato da MItaly
@simo_85: occhio, prova è un array di 30 char e stai scrivendo sul 31° => buffer overflow.

Si ho contato io male gli zeri prima di editare il post.. Poi sono uscito di casa e mi è venuto in mente... Comunque il problema è il carattere NUL..

[MItaly]

Originariamente inviato da Salvy95
E allora mi spieghi perchè sul dev c++ da problemi e sul code::blocks non da problemi?

Dipenderà dalle impostazioni con cui è stato compilato/dalla versione della CRT/da qualcos'altro ancora, probabilmente in un caso lo stack è "pulito" e dopo il buffer c'è della memoria inizializzata a 0, mentre nell'altro caso, o per chiamate interne alla CRT effettuate precedentemente o per qualche altro motivo, lo stack è "sporco" e ha su dei vecchi valori.

I compilatori spesso intervengono ad eliminare eventuali errori al codice

Cazzata. Il compilatore/la CRT semmai, in modalità debug, fa sì che gli errori siano più evidenti, ad esempio riempiendo le variabili e la memoria non inizializzate con pattern particolari e inusuali (come 0xCCCCCCCC), in modo che il programmatore se ne possa accorgere e li sistemi. Fare sì che un errore sia "invisibile" è la peggior cosa che un compilatore possa fare.
In effetti, tutti i meccanismi di sicurezza che ho visto inseriti dai compilatori per evitare gli stack overflow di default generano un crash del programma, in modo che il problema non passi inosservato.

[simo_85]

Originariamente inviato da Salvy95
E allora mi spieghi perchè sul dev c++ da problemi e sul code::blocks non da problemi?
I compilatori spesso intervengono ad eliminare eventuali errori al codice

Premesso che non uso altro che gcc, può essere che i compilatori vengono progettati con dettagli diversi. Il tutto è possibile, credo ma non ne sono sicuro, ma è il codice a non essere corretto.. Aldilà della mia errata correzzione una stringa termina sempre con il carattere NUL, e in quel codice il carattere NUL non viene assegnato a nessun elemento dell'array. Infine, credo che avere un compilatore che nasconde questi dettagli limita anche quello che si chiama un buon apprendimento o una buona programmazione, in questo caso in C.

[Salvy95]

Ragazzi ma mi avete frainteso, io non sto dicendo che non bisognava chiudere la stringa, se notate l'ho scritto anche sopra!
Sto solo dicendo che alcuni compilatori +provvedono a fare alcuni passaggi per te, adesso non mi viene niente in mente, quindi utilizzerò proprio quest'esempio:

il dev-c++ è come se non chiudesse la stringa
mentre il code::blocks non da problemi, quindi devo presupporre che la chiuda automaticamente...

io non sono esperto di c++, conosco soltanto un po' le basi...
sto solamente dicendo che lo stesso codice, pure se sbagliato, se compilato con un compilatore funziona, se invece se ne utilizza un altro no, e quindi è innegabile che qualcosa cambia da compilatore a compilatore.

MItaly, i dettagli tecnici non ci interessano, sopratutto se sparati con presunzione e volgarità.
Siamo su un forum, se non ti sta bene ciò che dice un utente è norma correggerlo con garbo ed educazione.