Is there a limit on the size of a char[] "string" branch?

ROOT
1

We have an old and conservative simulation framework where we write out extremely simple TTrees: no objects, no class dictionaries, just branches of single or array simple data types. This includes a number of old-style “strings” of the form

    char procname[80];
...
    hittree->Branch("Process", procname, "Process/C");

These all work fine, except for one which is declared very large:

    char config[4000];
...
    dettree->Branch("Config", config, "Config/C");

The char array is filled here using strncpy, just like all of our other “strings.” But when I look at the TTree in a ROOT session, that branch reports that it contains integer 0 values, not strings (and not even empty strings!). The other “string” branches properly report the character strings that were saved to them in the job.

Does ROOT have a limit on the size of an old-style char-array “string” that can be stored in a simple TBranch?

Please read tips for efficient and successful posting and posting code

ROOT Version: 6.12 or later
Platform: MacOS
Compiler: CLang

2

Hi @Michael_Kelsey,

Not, AFAIK.

Other than that, I couldn’t reproduce the problem in ROOT master (and my own test case). Could you provide a minimal reproducer?

Cheers,
J.

3

Thanks, Javier. Based on your conclusion, I stepped through our package’s initialization process in the debugger (ugh). It turns out that the problem is at my end, not ROOT’s.

The bit of code that does the filling of the “Config” branch (above) doesn’t get called until after our Geometry tree has already been written to the file. So of course at the time it’s written, those strings are empty (properly initialized).

It did confuse me that TTree::Scan() reports null strings with a numeric “0” value, rather than as “” or something more “stringy”, but that’s not important.

4

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.