Assumption about TBasket byte for JaggedArray was wrong

[reikdas]

Replace assumption with dummy value that reproduces correct behaviour

[jpivarski]

I don't see where in that reference "3" is revealed to be a safe value, but okay.

Does this have anything to do with the int8/char problem?

[reikdas]

I don't see where in that reference "3" is revealed to be a safe value, but okay.

The primary reason for this PR is to remove the false assumption and instead hardcode a value that we know works. (Even if all values > 2 work, we probably do not want to keep the old items.shape[0] + 1 in the codebase because it makes no sense and might lead to potential confusion when understanding the code or debugging in the future)
Also, all of my assumptions (for eg. about fEntryOffset and fNevBuf) were tested with the byte in question being set to a value that triggers this - https://github.com/root-project/root/blob/master/tree/tree/src/TBasket.cxx#L926-L928. I tested some values manually, and saw that 3 worked so I decided to go with 3.

Does this have anything to do with the int8/char problem?

Unforunately no.

[jpivarski]

That's definitely a good reason to do it. Misleading code is worse.

[reikdas]

@jpivarski Should we merge this? The travis tests are being shown as pending here, but if you click on them (go to the travis website), you will find that all the tests are green.

[jpivarski]

@jpivarski Should we merge this? The travis tests are being shown as pending here, but if you click on them (go to the travis website), you will find that all the tests are green.

Yeah, they are. I'm getting tired of Travis's quirks—Uproot 4 will either use Azure or GitHub Actions.