Newsgroup: it.comp.lang.c
Titolo: Segfault

Ho il seguente programma:
#include <stdlib.h>
#include <stdio.h>
int main()
{
    int i, k;
    char *bu;
    bu = malloc(30 * sizeof(char));
    for (i = 0; i < 100; i++) {
    if ((bu = realloc(bu, sizeof(char) * 30 + i + 1)) == NULL)
        return 1;
    for (k = 0; k < 30 + i; k++)
        bu[k] = 'j';
    bu[30 + i + 1] = '\0'; /* c'e' un + 1 di troppo... */
    printf("New: 0x%x, Size: %i\n", bu, strlen(bu));
    }
    free(bu);
    return 0;
}
Al momento dell'esecuzione:
New: 0x8049878, Size: 31
[...]
New: 0x8049878, Size: 92
Segmentation fault (core dumped)
Perche' non da un segfault subito al primo ciclo?
-- 
Fabio   fabio161616(at)
libero.it
 blackmagic(at)
penguinpowered.com
 
"Supporting Windows is like buying a puppy. The dog only cost $100,
but we spent another $500 cleaning the carpet."
               -- Marc Dodge

Perche' non da un segfault subito al primo ciclo?
Scrivere al di fuori della memoria allocata provoca un
segfault solo se sei "fortunato". Se sei sfortunato puo'
succedere di tutto (ad esempio la sovrascrittura di
altre variabili).
In generale in comportamento in questi casi e' dichiarato
"undefined" e significa che qualunque cosa succeda tu non
ti puoi lamentare, perche' te la sei cercata.
Una cosa che a volte non viene compresa e' che:
 1) undefined *NON* significa segfault
 2) undefined puo' anche significare che il programma
    prosegue correttamente (o *apparentemente* in modo
    corretto)
In C non esiste il concetto di "runtime error" che ti salva
quando qualcosa va storto. Ci sono ambienti in cui undefined
potrebbe tranquillamente significare ottenere la
formattazione del disco fisso (ad esempio MSDOS).
Su un sistema unix entrare nella regione 'undefined'
potrebbe tranquillamente portare la cancellazione di tutti
i file a cui l'utente in esecuzione ha accesso (e, per
programmi lanciati da root, anche la formattazione del disco).
Nella letteratura e' abbastanza comune l'esempio che dice
che un compilatore C potrebbe provocare la fuoriuscita di
demoni dal naso del programmatore in caso di sconfinamento
senza perdere la qualifica di compilatore ANSI C.
In poche parole NON e' possibile fare affidamento sui
segfault. A volte (se il programmatore e' fortunato) gli
sconfinamenti provocano dei segfault, ma l'assenza di
segfault non significa assolutamente che non ci siano
stati sconfinamenti.
Andrea
--
Andrea Griffini, Programmer
http://www.netservers.com/~agriff

 Perche' non da un segfault subito al primo ciclo?
Intanto hai dimenticato di includere string.h per strlen(). Con quello
pare funzionare ma non ho controllato bene il codice.
EMG

 stati sconfinamenti.
Ok, grazie per la precisazione.
Gia' che ci sono approfitto della tua disponibilita':
Ho notato che 'vi' carica in memoria tutto il file che deve editare,
questo e' un comportamento corretto? Non sarebbe meglio caricarlo un po'
alla volta, man mano che se ne fa richiesta?
Suppongo che questa scelta stata fatta considerando che 'vi' non ha a
che fare con grossi file e che c'e' un vantaggio in prestazioni, ma quanto 
a 'eleganza', qual'e' la soluzione migliore?
Poi, per aggiungere un carattere in una posizione n di un vettore di
caratteri, si preferisce una realloc() per fargli spazio, con il
successivo spostamento degli altri caratteri oppure creare un altro
vettore temporaneo per travasare il tutto?
Esiste documentazioni su queste decisioni stilistiche? (oltre
all'esperienza ;-) ).
Grazie.
-- 
Fabio   fabio161616(at)
libero.it
 blackmagic(at)
penguinpowered.com
 
Q:  Do you know what the death rate around here is?
A:  One per person.

all'esperienza ;-) ).
Hmmm... non ne ho idea. Io su realloc ho visto cosi' tanti
cattivi usi che preferisco evitarla.
