Fix/diagnostic gen error

[MSECode]

Updates for generic error translation from bits to string using this method motorStatusBitsToString

correlated to: #941 since it's rebased on that and it should be merged after
and it is directly related to: robotology/icub-firmware#472

Related to:
robotology/icub-firmware-shared#94
robotology/icub-firmware#472

[pattacini]

Hi @MSECode

Is this linked to #937?
Please, don't open up PR with a blank body 😉

[MSECode]

Yes
I know, I have to update it. I put in draft in the meanwhile as a placeholder

[valegagge]

Hi @MSECode,
I think here you could use the string_view for your map.
Moreover, concatenating the strings in this way means a lot of heap allocation.
We need to try to reduce them. We can discuss how to do it.
strcat is not the best way for safety reasons, but we can find a good solution for it.

PS: I know in the diagnostic parser I used some strings, but I want to improve it to reduce the heap usage anyway.

[MSECode]

let's add that point to the f2f discussion as well
So, we could do something like this:
constexpr std::string_view s_motor_fault_status[]{string1, string2, ....} so that it would also be evaluated at compile time

[pattacini]

Keeping this in draft until:

• Fix parsing data dimension in lost can boards error #941 is merged.
• Move MotorFaultState to EoMotionControl icub-firmware-shared#94 is merged.

[valegagge]

LGTM

[MSECode]

I need to update the CMakeLists.txt adding icub_firmware_shared::embot to fix compilation

[sonarcloud]

Quality Gate failed

Failed conditions
1 Security Hotspot
10.1% Duplication on New Code (required ≤ 3%)
C Reliability Rating on New Code (required ≥ A)

See analysis details on SonarCloud

Catch issues before they fail your Quality Gate with our IDE extension SonarLint

[pattacini]

Awaiting the CI before merging.

[MSECode]

Awaiting the CI before merging.

Ok, understood. I leave it running since I did not get any building error locally (since the compiler was probably able to find the embot library as installed on my system ) and I realized the missing of it just from the previous failing of the CI.
Is there a best practice I can use to simulate the job of the CI and so find any possible building error also locally (I'm thinking if could be useful in this case to use a virgin docker image but let me know what should be the best)?

Another point: regarding the Quality Gate. How should I consider the lines of code interested by a failing in the code analysis that have not been touched by the changes on the PR but still checked by SonarCloud?

[pattacini]

Is there a best practice I can use to simulate the job of the CI and so find any possible building error also locally (I'm thinking if could be useful in this case to use a virgin docker image but let me know what should be the best)?

Docker images are a possibility but somewhat limited to linux envs.
On Windows, there are maybe alternatives to create testing environments locally. One solution could be relying on Windows Sandbox, which in turn can be configured for the problems at hand.

Another point: regarding the Quality Gate. How should I consider the lines of code interested by a failing in the code analysis that have not been touched by the changes on the PR but still checked by SonarCloud?

We're not handling SonarCloud: no worries