Std::bitset streamer: endianness issue?

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() {

	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);



$> 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?


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

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

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)

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)


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


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