Std::bitset streamer: endianness issue?

[sbinet]

hi there,

I was adding support for reading/writing std::bitset<N> to groot when I noticed the following behaviour:

$> cat ./Event.h
#ifndef MYEVT_H
#define MYEVT_H 1

#include <bitset>

struct Event {
	std::bitset<16> Bs;
};

#endif // MYEVT_H

$> cat ./run.C
#include "Event.h"

void run() {
	gSystem->Load("./libEvent.so");

	auto f = TFile::Open("std-bitset.root", "RECREATE");
	auto t = new TTree("tree", "tree");

	int bufsize = 32000;
	int splitlvl = 99;

	Event e;
	e.Bs = std::bitset<16>("0001010111101010");

	t->Branch("evt", &e, bufsize, splitlvl);

	t->Fill();
	f->Write();
	f->Close();

	exit(0);
}

$> root -b -q ./run.C

reading back the file with groot, I see the following bit patterns:

$> root-dump testdata/std-bitset.root 
>>> file[testdata/std-bitset.root]
key[000]: tree;1 "tree" (TTree)
[000][evt]: {[0 1 0 1 0 1 1 1 1 0 1 0 1 0 0 0]}

ie: it seems endianness of the bitset isn’t handled when writing the bitset (and it’s whatever it happens to be on the writing machine).
(I was expecting: [0 0 0 1 0 1 0 1 1 1 1 0 1 0 1 0] as the on-disk bytes)

or are bitset<N> values always little-endian encoded?

thx,
-s

---

Please read tips for efficient and successful posting and posting code

ROOT Version: 6.22/02
Built for linuxx8664gcc on Aug 17 2020, 12:46:52
From tags/v6-22-02@v6-22-02

---

[sbinet]

if somebody (@pcanal?) could test on a big-endian machine?

[sbinet]

I was also a bit surprised to see a std::bitset<N> to take (N+4)bytes on disk (instead of “just” Nbits +4bytes, or, even, just Nbits).

is there an underlying reason I am missing here? (it’s also quite possible I am completely mistaken, of course)

[sbinet]

I’ve created an issue (root-project/root#6412) about this (both the endian-ness and the probably inefficient storage), but it’d be great to have some feedback about this. (either here or over there)

thanks.

[pcanal]

@sbinet

big-endian machine

humm … I should be able to do that … i’ll check next week.

Cheers,
Philippe.