[C] Allineamento dei campi delle struct: macro che vada bene e per GCC e per Visual S

[Vincenzo1968]

Ho installato il compilatore Intel:



http://software.intel.com/en-us/inte...llel-studio-xe

http://software.intel.com/en-us/non-...re-development



Ora debbo capire come si usa.

[Vincenzo1968]

Confermato. Si tratta di un bug di GCC a 32 bit. Compilando col compilatore Intel funziona tutto a meraviglia(anche senza allineamento):



E io che stavo impazzendo a cercare il bug nel mio codice...

[cdimauro]

Uomo di poca fede.

P.S. Anche GCC è farina del sacco di Stallman.

[Vincenzo1968]

Praticamente è da quando hanno deciso di sostituire bison con un parser a discesa ricorsiva scritto a mano che gcc presenta qualche bug...



Scheeeeeerzo

No, ma, a parte gli scherzi, vorrei segnalare il bug al team degli sviluppatori GCC. Vorrei mandargli i sorgenti del mio programma, il log di Valgrind, i test che ho effettuato e i risultati ottenuti. Come si fa? Chi debbo contattare? A chi debbo telefonare? Debbo prendere l'aereo e consegnare il tutto personalmente?

WarDuck, Cesare, Marco: grazie di cuore a tutti voi per i vostri preziosi consigli e suggerimenti. Senza di voi probabilmente starei ancora impazzendo cercando di scovare il bug. Un ringraziamento particolare a Marco per l'ottimo Valgrind.

[Vincenzo1968]

Alt! Fermi tutti!

In realtà ho sbagliato a passare il parametro per la compilazione a 32 bit: doveva essere -m32(come in GCC) e non -mia32.
compilando con -mia32 il parametro viene ignorato e viene prodotto un eseguibile a 64 bit(ecco perché funziona, come nel caso di GCC).
Me ne sono accorto col comando "file" che mostra se un file eseguibile è a 32 o 64 bit.

La compoilazione a 32 bit col compilatore Intel produce lo stesso errore segfault del compilatore GCC:


E dunque il bug è nel mio codice, non in GCC.
Ma intanto perché Valgrind mi indica il file mc_replace_strmem.c?

Invalid write of size 1
==30226== at 0x402C6C5: strcpy (mc_replace_strmem.c:438)
==30226== by 0x805CA2E: GetNextToken (scanner.c:296)

Si prospetta un gran bel fine settimana...

Adesso provo a sostituire le dichiarazioni dei tipi con quelli definiti in stdint.h, come suggerito da WarDuck.

[Vincenzo1968]

Anche col compilatore Intel se uso l'allineamento è tutto ok:



Mah!

[WarDuck]

Ti consiglio anche di sostituire la strcpy con strncpy, la variante che ti consente di specificare il numero massimo di bytes da scrivere nel buffer, è più sicura.

[Vincenzo1968]

Originariamente inviato da WarDuck

Ti consiglio anche di sostituire la strcpy con strncpy, la variante che ti consente di specificare il numero massimo di bytes da scrivere nel buffer, è più sicura.

Grazie WarDuck.
Ancora non ho sostituito le dichiarazioni dei tipi con quelli in stdint.h(ho lavorato di debug con Valgrind).

Faccio le sostituzioni che mi hai indicato e ti faccio sapere.

[marco.r]

Originariamente inviato da Vincenzo1968

Ma intanto perché Valgrind mi indica il file mc_replace_strmem.c?

Perche' e dove avviene lo sforamento. Il problema pero' direi che probabilmente sta nella funzione che lo chiama.
Puoi a valgrind di aprire il debugger quando incontra quell'errore, invece di continuare impunemente. Usare gdb da linea di comando non e' la cosa piu' piacevole del mondo, ma almeno dovresti poter vedere l'input al momento della chiamata e capire cosa c'e' di sbagliato negli argomenti.
Nel frattempo segui il consiglio di Warduck riguardo strncpy, e aumenta la dimensione dei buffer.

[Vincenzo1968]

Ho applicato le sostituzioni indicate da WarDuck ma il problema rimane. Resta comunque una buona pratica de seguire per la portabilità. D'ora in poi la adotterò.

Intanto ho isolato la parte di codice rognosa(grazie a Valgrind):

typedef struct nodeTypeTag
{
    nodeEnum type;
	enumTipo0 type0;			/* T_SIMPLE, T_ARRAY */
	enumTipo1 type1;			/* T_INTEGER, T_REAL, T_STRING, T_BOOLEAN */
	enumTipo2 type2;			/* T_CONST, T_VAR */

    /* union deve essere l'ultima voce in nodeType */
    /* perché operNodeType può crescere dinamicamente */
    union
	{
        PREFIX_ALIGNED constNodeType con SUFFIX_ALIGNED;			/* costanti */
        PREFIX_ALIGNED idNodeType id SUFFIX_ALIGNED;				/* identificatori */
        PREFIX_ALIGNED operatorNodeType opr SUFFIX_ALIGNED;		/* operatori */
    };
} nodeType;

E' la union a creare problemi a 32 bit. Sto modificando il codice per eliminarla.

Aho', 'sto Valgrind è favoloso! (anche da riga di comando)
Non c'è una versione per Windows(o qualcosa di simile)?

[Vincenzo1968]

Risoltoooooooooooooooooooooooooooooooooo!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[Vincenzo1968]

Non era la union. Era quella minchia di funzione con argomenti variabili.

Ho risolto così:

Questa la funzione incriminata(nel file "ast.c"):

nodeType *opr(int oper, int nops, ...)
{
    va_list ap;
    nodeType *p = NULL;
    size_t nodeSize;
    int i;

    nodeSize = SIZEOF_NODETYPE + sizeof(operatorNodeType) + (nops - 1) * sizeof(nodeType*);

    if ((p = (nodeType*)malloc(nodeSize)) == NULL)
	{
		printf("Errore: memoria insufficiente.\n");
		return NULL;
	}

    p->type = typeOperator;
    p->opr.oper = oper;
    p->opr.nops = nops;
    
    va_start(ap, nops);
    for (i = 0; i < nops; i++)
        p->opr.op[i] = va_arg(ap, nodeType*);
    va_end(ap);
   
    return p;
}

L'ho modificata così:

nodeType *opr(int oper, int nops, nodeType *p1, nodeType *p2, nodeType *p3)
{
nodeType *p = NULL;
    size_t nodeSize;

    nodeSize = SIZEOF_NODETYPE + sizeof(operatorNodeType);    

    if ((p = (nodeType*)malloc(nodeSize)) == NULL)
	{
		printf("Errore ast opr: memoria insufficiente.\n");
		return NULL;
	}
	
	p->type = typeOperator;
	p->opr.oper = oper;
	p->opr.nops = nops;
	p->opr.op[0] = p1;
	p->opr.op[1] = p2;
	p->opr.op[2] = p3;
     
    return p;
}

Senza Valgrind non ce l'avrei mai fatta. Grazie di cuore a Marco per avermelo segnalato.
Ti meriti un bacino sulla fronte. Tie': smackkkkkkkkkkkkkk.


Grazie di cuore anche a WarDuck e Cesare

Stallman for president

[Vincenzo1968]

Ovviamente funziona anche compilando coi compilatori Intel e CLang:

[marco.r]

Il link che ti avevo dato contiene riferimenti ad altri prodotti analoghi , alcuni dei quali disponibili pure per windows.
Ad esempio
http://www.drmemory.org/

Pero' non li ho mai usati e non li conosco (neanche di nome).

[Vincenzo1968]

Originariamente inviato da marco.r

Il link che ti avevo dato contiene riferimenti ad altri prodotti analoghi , alcuni dei quali disponibili pure per windows.
Ad esempio
http://www.drmemory.org/

Pero' non li ho mai usati e non li conosco (neanche di nome).

No no, che prodotti analoghi! Io mi sono innamorato di Valgrind. E' meraviglioso.

Minchia ti dice anche se lasci la memoria sporca perché ti sei dimenticato una free!

Come ho fatto per vent'anni a non utilizzarlo? E come ho potuto rinunciare a Linux per vent'anni? Ma come sono stato pazzo?



Bisogna avviarlo coi seguenti parametri:

--leak-check=full
--show-reachable=yes
--track-origins=yes
--log-file=outValgrind.txt

Per esempio:

valgrind --leak-check=full --show-reachable=yes --track-origins=yes --log-file=outValgrind.txt ./Contest1732 Files/prog01.txt

Edit: comunque ora provo 'sto Dr. Memory visto che è disponibile anche per Windows.

Riedit: Ahi! : Dr. Memory currently targets 32-bit applications only.