Found this bug using clang-tidy. There was an infinite recursion in the prepareHealthSetReply function
which is currently unused. Also includes all other clang-tidy suggestions
which made sense.
- Found this bug using `clang-tidy`. There was an infinite recursion in the `prepareHealthSetReply` function
which is currently unused. Also includes all other `clang-tidy` suggestions
which made sense.
This is unfortunate. I can't check this if I am using a more recent compiler. WE should consider upgrading the required version to C++17. Every project using the FSFW so far supports it anyway.
This is unfortunate. I can't check this if I am using a more recent compiler. WE should consider upgrading the required version to C++17. Every project using the FSFW so far supports it anyway.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
clang-tidy. There was an infinite recursion in theprepareHealthSetReplyfunctionwhich is currently unused. Also includes all other
clang-tidysuggestionswhich made sense.
@@ -45,2 +42,3 @@const object_id_t *objectId);ReturnValue_t prepareHealthSetReply(const CommandMessage *reply);[[maybe_unused]] ReturnValue_t prepareHealthSetReply(const CommandMessage *reply);[[maybe_unused]]is a c++17 featureThis is unfortunate. I can't check this if I am using a more recent compiler. WE should consider upgrading the required version to C++17. Every project using the FSFW so far supports it anyway.
@@ -14,3 +14,3 @@}CService201HealthCommanding::~CService201HealthCommanding() {}CService201HealthCommanding::~CService201HealthCommanding() = default;I would move the default to the header and remove the line here but I don't know if this is good practice.
Yeah, I can do that too and I have no idea what the best practice is. I think there is none. If i rewrote a header, I would do it there in the future.
okay, moved to header
LGTM