Disclaimer: I am not sure whether this is:

• 0 bug report (intented / wontfix),
• 1 or 2 bug reports.

Depending on feedback, We can close and / or I can create dedicated bugs.

Observations

There are two changes in 6.26.00:

• TRint exits hard for unknown arguments.
• TRint crashes when instantiated with *argc = nullptr and / or argv = nullptr which are the default values for TApplication and hence may be used by existing users of the TRint constructor.

Affected use cases

Applications may do something like:

TRint *app = new TRint("app", 0, NULL);
...
app->Run(kTRUE);

Applications may also use TRint during operation. One existing model some applications I use are employing is:

• Create a TRint shortly after startup, passing in argc and argv.
• Allow the user to drop to a ROOT interpreter prompt. This is then done by calling app->Run(kTRUE);. A user can use the interpreter to inspect state of the analysis software, and exit it again to let the software continue.

The latter approach is extremely useful for example to shell out after analysis software startup, or inside an event, such that the user can interactively analyze objects right from a ROOT interpreter shell.

Questions

• Is the use case "use TRint as class to drop into the interpreter" supported?
  The changelog of 6.26.00 reads like TRint is meant for internal use by root.exe only, but there seems to be no easy alternative.
  Depending on the reply, this could be a separate bug report, or a "wontfix".
• If the use case is / should be supported, It would be useful to be able to allow unsupported arguments to pass through, for use in applications which are not root.exe.
• For improved backwards compatibility and safety, not crashing when being passed *argc = nullptr and / or argv = nullptr would be nice.

In case somebody else is hit by this, I am right now using this hack as workaround:

                int dargc = 1;
                char** dargv = &argv[0];
                myApp = new TRint("myApp", &dargc, dargv, nullptr, 0, kTRUE);
                myApp->GetOptions(&argc, (argv));
                gSystem->SetProgname(argv[0]);

This allows to re-use the TApplication functionality as before, without triggering one of the two issues.