When is it a bug?

General Chat
1

Hello,

I am new to ROOT. Last week I started to get used to it. I first wanted to understand the interpreter language. I have encountered several cases of unexpected behaviour, of which I am not sure whether these are bugs or not. The reasons that I hesitate are twofold:

  1. I am a software developer, not a physicist, so my expectations may be different than the usual ones.
  2. I cannot find an exact description of the interpreter language. Rather I find some vague descriptions like “CINT covers about 95% of ANSI C and 85% of C++” (but I cannot find an exact description of the 5%-15% of differences, “CINT is not designed to be a 100% ANSI/ISO compliant C++ language processor. It is a portable scripting language environment, which is close enough to the standard C++.” (but “close enough” is not defined).

So it might be that unexpected behaviour is there because my expectations were wrong. This makes it difficult to decide whether something is a bug or not. I have two examples:

a) When I start a new ROOT session and I type

then ROOT exits with a large error dump.
I understand that ROOT cannot run when this object is deleted, but I expected that such an important object would be protected with e.g. a private destructor. Probably this is not a bug, but just a wrong expectation.

b) When I start a new ROOT session and I type

then ROOT exists also with a large error dump.
The documentation says that there is some support for the RTTI of C++.
typeid and dynamic_cast are the two most important operators for the RTTI. It seems that the typeid operator is known to the interpreter. Is it still wrong to expect some useful result from it?

I understand that it is difficult to explain when unexpected behaviour is a bug, but maybe someone can tell me when I should create a bug report.
As a newbie I hesitate to start creating a lot of bug reports.

2

Hi,

The known limitations are listed in the limitati.txt file available from root.cern.ch/twiki/bin/view/ROOT/CINT

delete gROOT;This is not a limitation of the interpreter but a misuse of a library object (ROOT’s). gROOT points to a global static object (actually a function static), deleting is not supported and lead to random behavior.

typeid(gROOT)should not crash and is a bug (well at least for now a limitation, the issue is that you do not seem to be able to take the typeid of a compiled object).

Cheers,
Philippe

3

I found this page, but the links to the limitations do not work (at least not for me). HTTP Response Status

404 Repository not found

4

The links have been fixed.

Philippe

5

I see that the links at the bottem of the page have been fixed, but not yet the links in the section “Limitations”.

6

The links in the limitation sections have also been fixed.

thanks,
Philippe

7

[quote=“pcanal”]

should not crash and is a bug (well at least for now a limitation, the issue is that you do not seem to be able to take the typeid of a compiled object).[/quote]

Not only for compiled objects. The following code crashes as well in the interpreter :frowning: :

namespace LocalNameSpace {

// Define a class and a class derived from it.

struct Parent_t {
virtual ~Parent_t () {};
};

struct Child_t : public Parent_t {
~Child_t () {};
};
}

void typeid2 () {

LocalNameSpace::Parent_t *P = new LocalNameSpace::Child_t;

cout << "Type of pointer: " << typeid §.name () << endl;
cout << "Type of pointed: " << typeid (*P).name () << endl;

delete P;

}

8

If I add#include <typeinfo.h> to your code, it works perfectly for me.

Cheers,
Philippe

9

[quote=“pcanal”]If I add#include <typeinfo.h> to your code, it works perfectly for me.
[/quote]

I still feel that a crash of ROOT when the include is missing is a bug.

Further, it runs now without crashing, but it displays the wrong type for Type of pointer. This should be “LocalNameSpace::Parent_t*” and not “LocalNameSpace::Child_t*”.

10

Hi,

I agree both are bugs :slight_smile:. We are currently updating the CINT backend; this will allow us to fix some of those issues once we are done.

Thanks for reporting this problem.
Philippe.