Allow non-zero starting event or subrun values

[michaelmackenzie]

This will allow making the current PBISequence detector steps file work properly, splitting a single subrun into multiple dts files without duplicate event numbers

[FNALbuild]

Hi @michaelmackenzie,
You have proposed changes to files in these packages:

• Sources

which require these tests: build.

@Mu2e/fnalbuild-users, @Mu2e/write have access to CI actions on main.

⌛ The following tests have been triggered for 37942eb: build (Build queue - API unavailable)

About FNALbuild. Code review on Mu2e/Offline.

[FNALbuild]

☀️ The build tests passed at 37942eb.

Test	Result	Details
test with	✅	Command did not list any other PRs to include
merge	✅	Merged 37942eb at 1d1b9f0
build (prof)	✅	Log file. Build time: 04 min 12 sec
ceSimReco	✅	Log file.
g4test_03MT	✅	Log file.
transportOnly	✅	Log file.
POT	✅	Log file.
g4study	✅	Log file.
cosmicSimReco	✅	Log file.
cosmicOffSpill	✅	Log file.
ceSteps	✅	Log file.
ceDigi	✅	Log file.
muDauSteps	✅	Log file.
ceMix	✅	Log file.
rootOverlaps	✅	Log file.
g4surfaceCheck	✅	Log file.
trigger	❓	Log file. Return Code 1.
check_cmake	✅	Log file.
FIXME, TODO	✅	TODO (0) FIXME (0) in 1 files
clang-tidy	➡️	2 errors 13 warnings
whitespace check	✅	no whitespace errors found

N.B. These results were obtained from a build of this Pull Request at 37942eb after being merged into the base branch at 1d1b9f0.

For more information, please check the job page here.
Build artifacts are deleted after 5 days. If this is not desired, select Keep this build forever on the job page.

[oksuzian]

Here's my review of PR #1799. I found a significant issue:

🐛 Unsigned Integer Underflow When firstSubRunNumber_ Is 0

On line 144, subRunNumber_ is initialized as:

      , subRunNumber_(firstSubRunNumber_ - 1U)

When firstSubRunNumber_ is 0 (the default), this computes 0U - 1U, which wraps around to 4294967295 (UINT_MAX) due to unsigned integer underflow. This is the same behavior as the old code (-1U), so it's intentionally relying on wrap-around — the value wraps back to 0 when subRunNumber_++ is called in readFile() at line 167.

While this works by accident of unsigned wrap-around semantics, this is still fragile and worth noting. The real issue is more subtle:

The Actual Bug: firstEventNumber_ Is Ignored for the First Sub-Run's Event Numbering

Look at the event numbering flow:

1. Constructor (line 145): currentEventNumber_ is initialized to firstEventNumber_.
2. readFile() (line 168): currentEventNumber_ is reset to 0 for every sub-run except the first one — good so far.
3. readNext() (line 210): Events use ++currentEventNumber_, which is a pre-increment.

This means:

• For the first sub-run, the first event number will be firstEventNumber_ + 1, not firstEventNumber_. If a user sets firstEventNumber: 5, the first event will actually be event 6.
• For subsequent sub-runs, events start at 0 + 1 = 1 (via pre-increment), meaning event numbering starts at 1, not 0.

If the intent is that firstEventNumber specifies the actual first event number, then the initialization should be:

      , currentEventNumber_(firstEventNumber_ > 0 ? firstEventNumber_ - 1 : 0)

Or alternatively, change the comment/documentation to clarify that firstEventNumber is an offset before the first event.

Summary of Issues

Issue	Severity	Location
Off-by-one in firstEventNumber_: First event is firstEventNumber + 1 due to pre-increment ++currentEventNumber_	🔴 Bug	Lines 145, 210
Unsigned wrap-around for subRunNumber_ initialization is intentional but could benefit from a comment	🟡 Style	Line 144

The off-by-one is the most important finding — if a user configures firstEventNumber: 100, they'll get events starting at 101, which would silently produce incorrect event numbering when splitting subruns across files.

[FNALbuild]

📝 The HEAD of main has changed to dceb1c9. Tests are now out of date.