#
c329ceea |
| 01-Sep-2023 |
Willy Tu <wltu@google.com> |
unpack: Support std::span as package arguments
Change-Id: Iae594c0d1b10e96dd4fd1a83cdf60c0757f9f3bd Signed-off-by: Willy Tu <wltu@google.com>
|
#
202702b0 |
| 15-Sep-2023 |
Jonathan Doman <jonathan.doman@intel.com> |
Fix std::optional maybe-uninitialized (maybe?)
Attempt to fix the GCC waybe-uninitialized warning for unpackArgs. It only triggers on compilation of one command handler (ipmiSensorGetDeviceSdrInfo)
Fix std::optional maybe-uninitialized (maybe?)
Attempt to fix the GCC waybe-uninitialized warning for unpackArgs. It only triggers on compilation of one command handler (ipmiSensorGetDeviceSdrInfo) with a single std::optional<uint8_t> param.
The warning is a false positive (I think) but GCC seems to like it if we get rid of the empty emplace() call in the underlying std::optional unpack function.
Tested: Compiles in the unit-test docker environment when configured with `meson setup --reconfigure build -Dwerror=true -Dwarning_level=3 --buildtype=debugoptimized`
Change-Id: Ida8b82dbf2227d3b5339cd4b5756729eeeea9e1d Signed-off-by: Jonathan Doman <jonathan.doman@intel.com>
show more ...
|
#
fbc6c9d7 |
| 10-May-2023 |
Patrick Williams <patrick@stwcx.xyz> |
clang-format: copy latest and re-format
clang-format-16 has some backwards incompatible changes that require additional settings for best compatibility and re-running the formatter. Copy the latest
clang-format: copy latest and re-format
clang-format-16 has some backwards incompatible changes that require additional settings for best compatibility and re-running the formatter. Copy the latest .clang-format from the docs repository and reformat the repository.
Change-Id: I44441096113929ce96eb1439e2932e6ff3c87f27 Signed-off-by: Patrick Williams <patrick@stwcx.xyz>
show more ...
|
#
b4905919 |
| 17-Jun-2022 |
Tim Lee <timlee660101@gmail.com> |
ipmid: message: fix pack/unpack compile error at aarch64 platform
After debugging with boost/multiprecision owner jzmaddock. We have found the root cause why boost v1.79.0 got this compile error in
ipmid: message: fix pack/unpack compile error at aarch64 platform
After debugging with boost/multiprecision owner jzmaddock. We have found the root cause why boost v1.79.0 got this compile error in ipmid. More detail you can refer from https://github.com/boostorg/multiprecision/issues/472
Root cause: Boost changed all bit counts from unsigned to std::size_t, specifically for platforms like arm64 (and windows!) where unsigned is narrower than size_t so that the maximum representable number isn't unnecessarily constrained.
This then changes the interface for cpp_int_backend to use size_t rather than unsigned for the bit counts. On most platforms and most use cases, this makes no perceptible difference, but unfortunately this appears to be one situation where it really does make a difference.
Apparently this is true even though:
template <unsigned N> using fixed_uint_t = boost::multiprecision::number<boost::multiprecision::cpp_int_backend< N, N, boost::multiprecision::unsigned_magnitude, boost::multiprecision::unchecked, void>>;
Is declared with an unsigned parameter, when partially specializing for fixed_uint_t you need to use the actual type of the template parameter in the underlying template, not the type used in the template alias!
Solution: Change all usage of unsigned for bitcounts to a new typedef bitcount_t which is size_t for Boost-1.79 and later, and unsigned for Boost-1.78 and earlier.
Verified: No compile error at aarch64 platform and test ipmitool sdr command is pass.
Signed-off-by: jzmaddock <john@johnmaddock.co.uk> Signed-off-by: Tim Lee <timlee660101@gmail.com> Change-Id: Id7a7c86ef854f4b9c06fc4da054c8021f76812b8
show more ...
|
#
997952af |
| 30-Jul-2021 |
Vernon Mauery <vernon.mauery@linux.intel.com> |
Add a SecureBuffer class SecureBuffer is like SecureString, but a specialization of std::vector<uint8_t> that cleans up after itself Tested: Executed various ipmi commands to se
Add a SecureBuffer class SecureBuffer is like SecureString, but a specialization of std::vector<uint8_t> that cleans up after itself Tested: Executed various ipmi commands to see that they still work Change-Id: Ifd255ef682d6e46d981de6a5a294d12f3666698b Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>
show more ...
|
#
caabc36b |
| 23-Jul-2019 |
Vernon Mauery <vernon.mauery@linux.intel.com> |
fix logic error for unpack vector of tuple Unpacking a vector of tuples is failing if the correct number of bytes does not match an integral number of bytes needed to fully unpack all
fix logic error for unpack vector of tuple Unpacking a vector of tuples is failing if the correct number of bytes does not match an integral number of bytes needed to fully unpack all the tuples. Unpacking a tuple should return an error if it does not fully unpack all the items. This will signal the vector unpack to bail and return however many items it has unpacked to that point. A vector unpack should always return success because no matter how many items it has unpacked, it is fine, because a vector can have any number of items. Tested: Unit tests updated to check for proper unpacking of vectors and tuples (and optionals) as well as new unit tests added for more targetted testing. Change-Id: I4b45198f8bc4a49913beb923d10079983179402a Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>
show more ...
|
#
a3dd7661 |
| 30-May-2019 |
Vernon Mauery <vernon.mauery@linux.intel.com> |
unpack static assert on unsupported types Unsupported types might not cause compile time errors but can result in SIGILL errors at runtime when compiler warnings are ignored. Th
unpack static assert on unsupported types Unsupported types might not cause compile time errors but can result in SIGILL errors at runtime when compiler warnings are ignored. This was found when compiling an intel-ipmi-oem handler that attempted to unpack an enum class type. The code compiles down to an empty function (no return statement or value), which can result in all sorts of undefined behavior. This change forces the unsupported types to emit a static assert and fail to compile. Tested: Created a handler that requests an enum class as an input and saw that the build fails with a static assert. Change-Id: I123da15cb001756f07761cf7a60b799469926a2a Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>
show more ...
|
#
51694c22 |
| 24-Apr-2019 |
William A. Kennington III <wak@google.com> |
message/payload: Clean up check / trailing state We want to be able to trivially re-use payloads for marshalling data from a buffer into other formats. This change tries to make the mean
message/payload: Clean up check / trailing state We want to be able to trivially re-use payloads for marshalling data from a buffer into other formats. This change tries to make the meaning of trailingOk and unpackCheck consistent, since the meanings didn't seem clear in the previous code. Now, unpackCheck is only used to determine if unpacking was checked, and trailingOk determines if unpackCheck is required. This also fixes lots of spurious warnings being printed for commands which were checking their output correctly, or were legacy and unable to check output. Change-Id: Id7aa9266693b4e3f896027acf6b3e5d757fdf981 Signed-off-by: William A. Kennington III <wak@google.com>
show more ...
|
#
0d49e479 |
| 08-Apr-2019 |
William A. Kennington III <wak@google.com> |
message/unpack: Fix undefined behavior It's UB to shift an integer by the size of that integer. More specifically, if you disable compiler optimization and try and unpack a 32 bit bi
message/unpack: Fix undefined behavior It's UB to shift an integer by the size of that integer. More specifically, if you disable compiler optimization and try and unpack a 32 bit bitset you will end up with a 0x0 mask. Avoid UB by replacing shift subtract with a negate shift. Tested: Unit tests pass now. Change-Id: I03a6f866a51c955b57787d641da9180841747e4c Signed-off-by: William A. Kennington III <wak@google.com>
show more ...
|
#
e7329c71 |
| 08-Oct-2018 |
Vernon Mauery <vernon.mauery@linux.intel.com> |
ipmid: Compiler-generated unpacking and packing of messages handler.hpp has the templated wrapping bits for ipmi command handler callbacks implemented. message.hpp has the seria
ipmid: Compiler-generated unpacking and packing of messages handler.hpp has the templated wrapping bits for ipmi command handler callbacks implemented. message.hpp has the serialization/deserialization of the ipmi data stream into packed tuples for functions. message/pack.hpp and message/unpack.hpp contain the actual serialization and deserialization of types. Change-Id: If997f8768c8488ab6ac022526a5ef9a1bce57fcb Signed-off-by: Vernon Mauery <vernon.mauery@linux.intel.com>
show more ...
|