I am not sure if it is expected behaviour, my bug, bug in ROOT or pyROOT.
I generate a tree with a string branch, which sometimes holds something, sometimes is empty. When I read the empty branch and print it in python it is OK until I encounter not empty branch. Not empty branch is also OK, but a following empty branch contains a modified string of the previous, not empty branch. For example, for not-empty and following empty branch:
In [10]: t.GetEntry(2)
Out[10]: 5
In [11]: t.br
Out[11]: 'aaaa\x00\x00'
In [12]: t.GetEntry(3)
Out[12]: 1
In [13]: t.br
Out[13]: '\x00aaa\x00\x00'
I attach a C(int) script to generate a tree and a python script to read and print it. test_read_tree.py (132 Bytes) test_tree.cpp (469 Bytes)
not bug … feature. At issue is that ‘char[200]’ could be some space containing a string, or it could be ‘byte[200]’ representing whatever (e.g. image or compressed/encoded data). Then, recovering a string by finding the null that otherwise terminates it is easy, but if PyROOT were to truncate the string, recovering data would not be possible at all. The size of the returned string is determined by the buffer size in use (leaf->GetNdata()).
In your case, find the ‘\x00’ (i.e. ‘\0’) and truncate the strings on that.
Yes, I did it already. However this does not seem to be the standard behaviour - print prints such strings and probably some other functions also can make (improper) use of them. I mean - you have empty string in the Tree and receive a not empty, usable string in python. No problem for me, but can be a reason of a few surprises/bugs for some users in the future.
I know, but I don’t have a better idea. Perhaps returning an actual char array (array.array(‘c’,[])) would have been the less confusing, but ‘history’ has since been built up.