[ANSI C] Codice che non funziona

[ingframin]

Buon giorno,
ho bisogno di capire cosa sbaglio:

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


int main(void) {

	char* input = "";

	printf("F01 VM, v1.0\n");
	printf("=>");

	while(1){

		scanf("%s",input);
		if(strcmp("exit",input)==0){
			break;
		}

	}
	return EXIT_SUCCESS;
}

In pratica non esegue le printf se non dopo aver scritto "exit", cosa alquanto singolare considerato che le printf sono fuori dal loop.
È un problema di settaggi del compilatore?
(lo so che "=>" dovrebbe stare dentro al loop, è solo una prova e non cambia il risultato)

[wingman87]

http://stackoverflow.com/questions/1...e-format-strin

Io farei il flush di stdout

[ingframin]

Grazie!
Ora funziona perfettamente

[wingman87]

Originariamente inviato da ingframin

Grazie!
Ora funziona perfettamente

Prego!
In verità il tuo caso è un po' strano perché il newline c'è nella prima printf, quindi almeno quello avrebbe dovuto stamparlo subito. Se non è così probabilmente c'è qualche motivo legato alla compilazione o al sistema in cui stai eseguendo il codice.

[ingframin]

Originariamente inviato da wingman87

Prego!
In verità il tuo caso è un po' strano perché il newline c'è nella prima printf, quindi almeno quello avrebbe dovuto stamparlo subito. Se non è così probabilmente c'è qualche motivo legato alla compilazione o al sistema in cui stai eseguendo il codice.

Credo che sia dovuto all'IDE.
Ho provato il codice da dentro Eclipse (nella console integrata) e da Visual Studio ( sempre nella console integrata).
Sono abbastanza convinto che se lo avessi eseguito da terminale non avrei avuto problemi.
Appena ho tempo più tardi provo.

[van9]

Originariamente inviato da ingframin

    char* input = "";
    ...
    scanf("%s",input);

...

[Ziosilvio]

Originariamente inviato da ingframin

	char* input = "";

	printf("F01 VM, v1.0\n");
	printf("=>");

	while(1){

		scanf("%s",input);

E già per questo io ti avrei bocciato all'esame

Non si deve chiamare scanf con l'opzione %s e un puntatore a una zona di memoria inizializzata male, o non inizializzata affatto.
Quando tu dichiari char * input = "", input è un puntatore ad una locazione di memoria X che contiene il carattere zero. Non hai però nessuna garanzia che da X in poi ci sia abbastanza spazio per copiare tutto il contenuto dello standard input fino all'andata a capo, e meno che mai che facendo la copia non si vada a sovrascrivere delle regioni importanti della memoria!

Su che libro stai studiando?
Io ti consiglio di ripassare prima tutta la parte sulle stringhe di caratteri, e poi bene il funzionamento di scanf.
Dopodiché, leggi anche il funzionamento di fgets.
Infine, ti consiglio di prendere buona abitudine di usare fgets e non scanf quando devi leggere una stringa di caratteri.

[sottovento]

Originariamente inviato da Ziosilvio

Non si deve chiamare scanf con l'opzione %s e un puntatore a una zona di memoria inizializzata male, o non inizializzata affatto.

Cosa ti hanno fatto le zone di memoria non inizializzate? Basta che siano valide, no?

scanf("%s", (char *)0x800000);

[WarDuck]

Originariamente inviato da sottovento

Cosa ti hanno fatto le zone di memoria non inizializzate? Basta che siano valide, no?

scanf("%s", (char *)0x800000);

Ci sono diversi casi che mi vengono in mente per il codice postato da ing.

Se il compilatore capisce che quella è una stringa vuota e quindi non alloca area nella regione testo allora quel puntatore chissà a cosa è inizializzato (sarebbe curioso fare una print del puntatore).

Se viceversa il contenuto di input si trovasse nella regione dati non modificabili, in teoria il programma dovrebbe crashare in quanto area read-only...

Detto ciò un programmatore dovrebbe sempre sapere cosa sta facendo, quindi dovrebbe allocare la giusta memoria che gli occorre senza sperare che l'implementazione di turno lo grazi.

Tanto per la cronaca comunque, in sistemi con ALSR e randomizzazione dello spazio degli indirizzi (tutti i sistemi Linux moderni ce l'hanno attiva di default) non si può fare affidamento agli indirizzi di memoria logici in quanto cambiano da un esecuzione all'altra del codice (uno dei meccanismi di protezione da buffer overflow e quant'altro).

Edit: provato ora il programma di ing...

giulio@server:~/Programs/ing$ ./a.out
F01 VM, v1.0
=>exit
Segmentation fault

Come prevedibile la stringa è in una regione dati non modificabili.

[ingframin]

Non ho postato il codice intero, nella versione finale quel puntatore è un array di 32 caratteri.
Il mio problema era la stampa con printf, non il puntatore. Per altro da windows quel codice gira anche senza inizializzare affatto il puntatore (magie di visual studio credo...).
Non pensavo con 2 righe di C di scatenare un putiferio del genere.
Inoltre non capisco perché non usare scanf che è così comoda...
Ma in ogni caso sono arrugginito, non scrivo codice C da parecchio e non mi pare il caso di scatenare un putiferio per un errore del genere.
@Ziosilvio: non sto studiando per un esame dell'università, quella purtroppo è finita anni or sono

Ultimo snapshot prima di collassare per via della febbre

 
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "isa.h"
 
int main(void) {
 
    char input[32];
 
    printf("F01 VM, v1.0\n");
    fflush(stdout);
 
 
    while(1){
        printf("=>");
        fflush(stdout);
        scanf("%s",input);
        if(strcmp("exit",input)==0){
            break;
        }
        IR = 0xAAFFFFFF;
        execute();
        printf("%d\n",PC);
        printf("%d\n",IR);
        printf("%d\n",SP);
        printf("%d\n",flag);
        fflush(stdout);
    }
    return EXIT_SUCCESS;
}

[WarDuck]

Originariamente inviato da ingframin

Non ho postato il codice intero, nella versione finale quel puntatore è un array di 32 caratteri.
Il mio problema era la stampa con printf, non il puntatore. Per altro da windows quel codice gira anche senza inizializzare affatto il puntatore (magie di visual studio credo...).
Non pensavo con 2 righe di C di scatenare un putiferio del genere.
Inoltre non capisco perché non usare scanf che è così comoda...

Tranquillo non c'è problema . Riguardo all'ordine della print, sul mio sistema non lo fa, quindi potrebbe essere dovuto alla specifica implementazione (io ho provato su Debian 7), ma ho compilato senza ottimizzazioni attive.

Se non inizializzi il puntatore esso può puntare ovunque, quindi se ti dice bene può darsi che non causi crash, ma ovviamente non puoi confidare in questo.

Riguardo scanf, il problema è che non fa controlli sulla lunghezza del buffer, infatti tu non dici a scanf quanto deve leggere dall'input.

Ora con tutti i meccanismi di protezione di oggi il programma ti crasha in qualsiasi caso se passi più di 32 bytes. Senza quei meccanismi di protezione un attaccante potrebbe causare stack overflow ed eseguire codice arbitrario.

Con fgets invece devi specificare quanto vuoi leggere, quindi è una funzione più sicura, ti consiglio di usare quest'ultima.

[ingframin]

Originariamente inviato da WarDuck

Tranquillo non c'è problema . Riguardo all'ordine della print, sul mio sistema non lo fa, quindi potrebbe essere dovuto alla specifica implementazione (io ho provato su Debian 7), ma ho compilato senza ottimizzazioni attive.

Se non inizializzi il puntatore esso può puntare ovunque, quindi se ti dice bene può darsi che non causi crash, ma ovviamente non puoi confidare in questo.

Riguardo scanf, il problema è che non fa controlli sulla lunghezza del buffer, infatti tu non dici a scanf quanto deve leggere dall'input.

Ora con tutti i meccanismi di protezione di oggi il programma ti crasha in qualsiasi caso se passi più di 32 bytes. Senza quei meccanismi di protezione un attaccante potrebbe causare stack overflow ed eseguire codice arbitrario.

Con fgets invece devi specificare quanto vuoi leggere, quindi è una funzione più sicura, ti consiglio di usare quest'ultima.

Buono a sapersi, usero fgets per il prompt.
Sto riscrivendo un piccolo emulatore che ho scritto in python. La scanf nel loop mi serve solo in debug, la versione finale si limita a leggere da file.
Per quanto riguarda il puntatore penso che probabilmente visual studio, quando esegui in "debug mode" ha una specie di sand box, perciò non crasha. È una mia ipotesi eh, non ho controllato.
Comunque ho capito il problema e concordo che può essere pericoloso usare aree di memoria non inizializzate.
La printf sono abbastanza sicuro che non ha bisogno di nessun fflush se il programma gira in un terminale linux, infatti è la prima volta che vedo questo effetto perché è la prima volta che provo da windows