suter_aandClaude Opus 5
618e96fb00
Build and Deploy Documentation / build-and-deploy (push) Successful in 27s
Three unrelated issues made the musrview_check tests fail on macOS while
passing on Linux.
1. Unspecified argument evaluation order
TColor::GetColor(rand.Integer(255), rand.Integer(255), rand.Integer(255))
evaluates its (side-effecting) arguments in an unspecified order: clang
goes left-to-right, gcc right-to-left, so the same seed yielded RGB on
one platform and BGR on the other. Visible whenever more runs are
plotted than the startup xml colour list provides, e.g.
test-histo-HAL9500.msr with 16 runs against 10 colours.
The rgb values are now drawn into separate variables first. This keeps
the clang result and changes gcc to match, hence the regenerated
reference PNG for musrview-histo-HAL9500 (99.94% of the differing
pixels were exact R<->B swaps).
Fixed in PMusrCanvas, PFourierCanvas and both mupp PMuppCanvas copies.
2. Fixed size path buffers
char fileName[128] plus strncpy(dst, src, sizeof(dst)) truncates *and*
leaves the buffer unterminated once the path reaches the buffer size.
musrview then failed on a 132 character msr-path in doc/examples/ViewOpts.
musrFT and musrt0 were worse: an unbounded strcpy of the startup file
path into char startup_path_name[128], i.e. a stack buffer overflow.
All path/filename buffers in the drivers are now std::string:
musrview, musrFT, musrt0, musrfit, any2many, addRun, dump_header.
PMusrCanvas::SaveGraphicsAndQuit() takes const Char_t* accordingly.
Along the way in the same files:
- msr2msr_replace() wrote a 256 byte line into char temp[128]
- msr2msr assembled "cp"/"rm" shell commands from paths in a 256 byte
buffer; replaced by std::filesystem
- msr2msr and addRun read lines with getline(buf, N), which silently
abandons the rest of the file on the first over-long line
- addRun: bound the unbounded sscanf "%s" to "%255s"
- dropped scratch buffers that only held a string literal, in favour of
TString::ReplaceAll(const char*, const char*)
3. musrview_check.py left its PNGs behind on failure
The two early error returns skipped the cleanup, and since generated
PNGs were identified by "not in the pre-run snapshot", one leftover file
permanently masked the real output of that test: musrview overwrites the
stale PNG, so it was there, just filtered out. One failure thus poisoned
every later run (30 of the 37 observed failures) after a 15 s poll each.
Cleanup now runs in a finally block on every exit path, and generated
PNGs are detected by mtime instead, which sees rewritten leftovers while
staying safe for a sibling test running concurrently under ctest -j.
Also dropped the MUSRVIEW_PNG_DIR env var and its tmp-dir fallback: it
is read nowhere in src/, so the fallback was dead code that guaranteed
the full 15 s poll before every "no PNGs found" failure.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>