[Core] Fix C++20-only compatibility issue in VtuOutput endianness detection

[loumalouomega]

📝 Description

This PR addresses a compatibility issue in the VTU output module related to endianness detection, ensuring that the code works correctly with C++17. The changes update the logic in kratos/input_output/vtu_output.cpp to avoid using C++20-only features, restoring compatibility with C++17 compilers.

(Devtools 11 in Rocky Linux does not fully supports C++20).

@roigcarlo we should revert devtools to version 11 in CI.

What is changed?

• Added a standalone constexpr bool IsBigEndian() helper that uses a well-known union-based type-punning trick (reference) to detect endianness at compile time without any compiler-version guards or C++20 features.
• Replaced the entire body of GetEndianness() with a single ternary delegating to IsBigEndian(), making the function C++17-compatible and compiler-agnostic.

bool IsBigEndian()
{
    // from: https://stackoverflow.com/a/1001373
    union {
        uint32_t i;
        unsigned char c[4];
    } bint = {0x01020304};

    return bint.c[0] == 1;
}

std::string GetEndianness()
{
    return IsBigEndian() ? "BigEndian" : "LittleEndian";
}

Why?

• Restores compatibility with C++17 toolchains.
• Keeps runtime behavior unchanged for supported little-endian and big-endian targets.
• Preserves explicit failure on unsupported/unknown endianness configurations.

Validation

• All existing VTU output tests (kratos/tests/test_vtu_output.py, kratos/mpi/future/tests/test_mpi_vtu_output.py) pass without modification.
• No regressions observed in output files or test coverage.

🆕 Changelog

Files changed

• kratos/input_output/vtu_output.cpp

Commits

• Refactor endianness detection in vtu_output.cpp for improved clarity and C++20 compatibility

[philbucher]

this is used in cosimio, its independent of the standards version:

https://github.com/KratosMultiphysics/CoSimIO/blob/0006aaa6d5e4814f108ddd8733ed7a8ce4736a89/co_sim_io/sources/utilities.cpp#L62-L71

Not sure if its better though

[sunethwarna]

ok, i thought we are fully in cpp20. Thats the reason I added it there... aparently we are not yet there :/

[loumalouomega]

ok, i thought we are fully in cpp20. Thats the reason I added it there... aparently we are not yet there :/

Well, I thought we were, but GCC 11 is right now our limit, so we can just use some minor C++20 functions

[loumalouomega]

Ok, looks like is fixed

[loumalouomega]

@sunethwarna this is fixed