[OT] Compilatore g++ v3.4.2 ha un problema

[thantrax]

Salve,
voglio comunicarvi la mia scoperta di un BUG , perchè tale si
tratta nel compilatore citato nell'oggetto. In particolare, si tratta di un BUG, in compilazione, che fa operare g++ su codice critico senza dare alcun avvertimento. Vi prego, pertanto, di verificare anche voi questa cosa tramite il coice c++ allegato. La parte che
smaschera il bug sta nelle ultime 4 linee di codice del main. Io
ho verificato l'assoluta mancanza di warning, per non parlare del fatto che l'eseguibile viene generato. Tutto è stato provato su
Windows 2000 (SP3) ma consiglio di verificare tale comportamento con altre versioni di g++, coi compilatori microsoft (.NET escluso) e
borland. Per quanto riguarda il mondo linux lasco fare a chi ne sa più di me. Spero che la cosa possa essere utile.

P.S.
Se non sapete che versione si g++ avete, da linea di comando digitate:

g++ --version



P.P.S.
Ho spedito una email a Bjarne Stroustrup e lui, a quanto pare, ne ha
informato quelli di GNU. Speriamo bene.

[Ikitt]

Originariamente inviato da thantrax
[...]Vi prego, pertanto, di verificare anche voi questa cosa tramite il coice c++ allegato.[...]

Allegato dove?

[thantrax]

Salve,
a quanto pare riesco a individuare un bug in un compilatore
c++ ma non ad allegare un file ad un messaggio (...nessuno è
perfetto). Quindi aggiungo il codice in coda a questo messaggio:

TIA

1) *** header file ***

// Header
//
#ifndef EX_04_0013_H
#define EX_04_0013_H

struct Point
{
int x;
int y;
};

class CPoint
{
private:
Point p;
public:
CPoint();
~CPoint();
void set(Point);
void draw(void) const;
};

class CLine
{
private:
Point p1;
Point p2;
public:
CLine();
~CLine();
void set(Point, Point);
void draw(void) const;
};

class CDraw : public CPoint, public CLine
{
private:

public:
CDraw();
~CDraw();
void draw(void) const;
};

#endif // EX_04_0013_H

2) *** c++ file ***

// Inherited sample
//
#include <iostream>
#include "Ex_04_0013.h"

using namespace std;

CPoint::CPoint(void)
{
cout << "-> CPoint" << endl;
p.x = 0;
p.y = 0;
}

CPoint::~CPoint(void)
{
cout << "<- CPoint" << endl;
}

void CPoint::set(Point pt)
{
p.x = pt.x;
p.y = pt.y;
}

void CPoint::draw(void) const
{
cout << "CPoint draw" << endl;
}

CLine::CLine()
{
cout << "-> CLine" << endl;
p1.x = 0;
p1.y = 0;
p2.x = 0;
p2.y = 0;
}

CLine::~CLine()
{
cout << "<- CLine" << endl;
}

void CLine::set(Point pt1, Point pt2)
{
p1 = pt1;
p2 = pt2;
}

void CLine::draw(void) const
{
cout << "CLine draw" << endl;
}

CDraw::CDraw(void)
{
cout << "-> CDraw" << endl;
}

CDraw::~CDraw(void)
{
cout << "<- CDraw" << endl;
}

void CDraw::draw(void) const
{
cout << "CDraw draw" << endl;
}

void func1(CPoint& p)
{
Point x = {0,0};
p.set(x);
p.draw();
};

void func2(CLine& l)
{
Point x1 = {0,0};
Point x2 = {10,10};
l.set(x1,x2);
l.draw();
};

int main()
{
Point p = {1,1};
Point p1 = {1,20};
Point p2 = {10,20};

CPoint P;
P.set(p);
P.draw();

CLine L;
L.set(p1,p2);
L.draw();

CDraw d; // dreived <- public CPoint, public CLine

// Upcasting...

func1(d); // -> CPoint
func2(d); // -> CLine

CLine* ll = &d;
ll->draw(); // -> CLine
CPoint* pp = &d;
pp->draw(); // -> CPoint
CPoint& mm = d;
mm.draw(); // -> CPoint

CLine* lo;
lo = new CDraw();
lo->draw(); // -> CLine
delete lo;

CPoint* po;
po = new CDraw();
po->draw(); // -> CPoint
delete po;

cout << "*** THE CODE ***" << endl;

CDraw* dx;
dx->CPoint::draw();
dx->CLine::draw();
dx->draw();
}

[Ikitt]

Originariamente inviato da thantrax
[...] La parte che
smaschera il bug sta nelle ultime 4 linee di codice del main. Io
ho verificato l'assoluta mancanza di warning, per non parlare del fatto che l'eseguibile viene generato.[...]

Confermo sia l'assenza di warning (pure con -Wall -pedantic) sia il bug con g++ 4.0.1. Strano pero`.

[oregon]

Scusa, ma visto che l'hai scoperto, vuoi descriverlo un po' meglio il bug ...?

[thantrax]

Salve,
innanzitutto grazie per aver verificato la cosa. Devo
dire che la presenza di un bug non è affatto strano. Se c'è una parte più critica dello sviluppo di software (...i compilatori sono anch'essi software) è la fase di test. E' evidente che quelli di GNU si sono dimenticati di fare un test (...e speriamo che si siano limitati a quello) per quanto la notizia che con la v4.x le cose non cambiano mi lascia perplesso, se non altro perchè non vorrei che cominciassero a fare concorrenza a quelli della microsoft (...concorrenza nel creare bug, intendo).
Per quanto riguarda il bug in se, la sua importanza non sta nel fatto che l'eseguibile venga generato. Il fatto per me grave sta nella mancanza di warning in compilazione (cosa
che non avviene con VC++ 6.0 e C++Builder 6.0) e ancora di
più nel fatto che l'eseguibile, fatto girare, non solleva
nemmeno una dannata eccezione (...così è sul mio PC).
Circa il perchè un warning dovrebbe esseerci dovrebbe
essere chiaro a chi sa di puntatori, di classi e di corretto utilizzo di oggetti. Per chi non lo sapesse consiglio di
scaricarsi dal web "Thinking in C++" di Bruce Eckel. Il libro è gratis ed è valido (anche se in inglese), oltre ad essere più facile dei testi di Bjarne Stroustrup.
Se qualcuno ha qualcosa da aggiungere in merito, non
se ne faccia un problema e, se ne ha la possibilità, informi anche altri utilizzatori dei compilatori g++ circa quello
che è venuto fuori.

TIA

[Ikitt]

Originariamente inviato da thantrax
Devo dire che la presenza di un bug non è affatto strano.[...]

Non mi ha colpito tanto la presenza in se di un bug, quanto il fatto che il bug in questione si presenta in una situazione che non mi pare un caso particolare, strano, o che non verrebbe in mente di sottoporre a test insomma.
Oltretutto, gcc solitamente non manca di emettere warning per l'uso di variabili non inizializzate, e questo contribuisce alla mia sorpresa. Sinceramente sono molto arrugginito col C++, non saprei quindi dire se la situazione presentata potrebbe, anche solo lontanamente, mettere in crisi il compilatore per qualsivoglia motivo, anche se sinceramente non mi pare, di primo acchito.
L'importante, comunque, e` che il bug sia stato riportato agli autori di gcc

Circa il fatto che non venga neppure sollevata un'eccezione: in base ai miei ricordi dello standard C++, questo non dovrebbe essere scorretto. Indesiderabile molto probabilmente si, ma non scorretto

[thantrax]

Salve,
vedo con piacere che la notizia oltre ad essere letta
viene anche discussa. Credo, allora, che sia meglio fare chiarezza su alcune code:

1) Il warning sul codice in questione fa parte dello standard implementativo del C++ (vedi Bjarne Stroustrup)
2) Microsoft VisualC++ 6.0 da un warning in compilazione e solleva delle eccezioni in esecuzione
3) Borland C++Builder 6.0 non da un warning ma solleva delle eccezioni in esecuzione
4) Un compilatore c++, che pretende di rappersentare una valida alternativa (per Windows e Linux), non fa un'accidente di niente.
5) Se io ho speso cinque minuti per sviluppare un'esempio di codice capace di evidenziare un bug nel compilatore, penso che quelli di GNU potevano fare altrettanto (...o devo pensare che loro sono troppo bravi per banalità come questa?)
6) Questa situazione mi fa venire in mente l'Apollo 13 che, per una serpentina che costava alcuni centesimi di dollaro, una banalità rispetto ad un progetto di chissà quanti milioni di dollari, mise a rischio le vite di tre uomini e bloccò la NASA per intere settimane/mesi al fine di far tornare quegli astronauti sulla Terra, vivi.

Conclusione: per me almeno un warning ci deve essere alrimenti, a seguire la filosofia pragmatica del c++, finirà che con g++ si protranno fare vaccate peggiori che usare un puntatore ad oggetto senza prima inizializzarlo.

TIA

[anx721]

Ma il bug è riferito al fatto che si invoca un metodo su un puntatore non inizilizzato?

se è cosi, sicuro che si trata di un bug? l'uso di variabili non inizializzate dovrebbe produrre effetti indefiniti, compreso quello di far funzionare tutto come se non ci fosse errore.

[Ikitt]

Originariamente inviato da anx721
se è cosi, sicuro che si trata di un bug? l'uso di variabili non inizializzate dovrebbe produrre effetti indefiniti, compreso quello di far funzionare tutto come se non ci fosse errore.

E` un dubbio che e` sorto anche a me strada (thread) facendo, ma non ho ancora trovato riferimenti certi, e non ho lo standard sotto mano.
Sicuramente un warning in compilazione sarebbe comunque gradito.