phosphor-host-ipmid/include/ipmid/message, branch master

fix logic error for unpack vector of tuple

2019-09-16T20:12:11+00:00

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

unpack static assert on unsupported types

2019-05-30T23:54:57+00:00

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

message/pack: Allow packing payloads

2019-04-29T19:06:35+00:00

Some IPMI handlers need the ability to support variable return types. The easiest way to do that is to be able to return payloads and pack them into the final payload. Change-Id: I5098a1ab0998ada712096929eae40a3c88a6dea0 Signed-off-by: William A. Kennington III

message/pack: Support packing string_views

2019-04-29T19:06:35+00:00

Now we don't need to make an intermediate copy of our data into an array before packing it into a payload. Change-Id: Iac79a79e0ae95835cb67d617a966a92ce8dcd5f8 Signed-off-by: William A. Kennington III

message/pack: Check for outstanding bits

2019-04-29T19:06:35+00:00

Currently, if you pack a non-byte aligned member into a message and then pack an array, it will do the wrong thing and treat the unaligned data as being appended to the end of the message. Allowing for this behavior is convoluted and probably not useful, so just return an error. Change-Id: I6f200dbea96c41f49a110ba7536ccfd37115d277 Signed-off-by: William A. Kennington III

message/payload: Clean up check / trailing state

2019-04-29T19:06:35+00:00

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

Fix compilation warning regarding std::variant

2019-04-16T02:57:47+00:00

When building with SDK, the compiler complains about ’variant’ being not a member of ’std’: .../pack.hpp:249:24: error: ‘variant’ is not a member of ‘std’ This commit adds appropriate #include to fix that. Change-Id: I99d6b7c17cbe1f49d706821797cf3fa03ca8c26a Signed-off-by: Alexander Amelkin

message/unpack: Fix undefined behavior

2019-04-12T01:40:25+00:00

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

Add a tuple type for packing

2019-04-09T17:42:38+00:00

At the top level, payload had the ability to pack a tuple, but it did it by splitting it into its parts and packing those individually. But if one of those parts was a tuple, it would fail. This moves the tuple packing code into the packing templates so that it is possible to pack a nested tuple of tuples. Tested-by: newly written tuple unit tests pass Change-Id: Icd80926314072df78b0083a823dcfb46e944e365 Signed-off-by: Vernon Mauery

Add error message to build to make packing type errors clear

2019-04-09T17:39:06+00:00

Because the base template actually handles things (all integer types), it needs to ward off non-integer types in a clear way, rather than relying on the user seeing that a tuple doesn't have an operator <<(), for example. This provides a clear message if a specialized pack operation was not hit. Tested-by: attempted to build with a non-supported pack type Change-Id: I66280831e88b4eac903b89f523e5f1a56a53cf9d Signed-off-by: Vernon Mauery