Lengthen allowable unit test names

[asgibson]

Describe the bug
Not sure if it is a bug, but why is the TestName length based upon OS_MAX_API_NAME*2 in utglobal.h?

To Reproduce
Steps to reproduce the behavior:

1. Write a unit test with a name longer than OS_MAX_API_NAME*2
2. Run tests and see that the test name is truncated

Expected behavior
Provide enough space for long (descriptive) test names.

Code snips

osal/ut_assert/src/utglobal.h

Line 53 in 8cfd6fe

char TestName[OS_MAX_API_NAME*2];

char    TestName[OS_MAX_API_NAME*2];

System observed on:

• PC
• RHEl 7.6
• current 'master' branch

Additional context
This is only an issue because I use long descriptive test names.

Reporter Info
Alan Gibson
GSFC, Code 587

[skliper]

Make it 120 and submit a PR?

[asgibson]

That will solve my issue.

I am still curious if there is reasoning behind the setting. If there is a reason, then setting it to 120 may be breaking that. If there is not a reason then, I'll do it for sure.

[skliper]

Make it 128 to match CompleteTestName used in cFE for UT_AddSubTest. They don't have to match (safely truncates), but no point making it smaller.
Note

osal/ut_assert/src/utassert.c

Line 45 in 8cfd6fe

static char CurrentSegment[64];

should also be 128.
It's also 128 at

osal/ut_assert/src/utbsp.c

Line 101 in 8cfd6fe

char ReportBuffer[128];

[asgibson]

Excellent. Thank you for the review. I will change both and PR.

[asgibson]

I cannot make the change because there is a conflict and we're entering a seesaw situation.
I request this be elevated to a higher level design discussion.

Blame reveals there was already a change to

osal/ut_assert/src/utassert.c

Line 45 in 8cfd6fe

static char CurrentSegment[64];

in #534 it changed from 128 to 64, also changed was this

osal/ut_assert/src/utassert.c

Line 79 in 8cfd6fe

char ReportBuffer[144];

ReportBuffer went from 128 to 144, but this is not

osal/ut_assert/src/utbsp.c

Line 101 in 8cfd6fe

char ReportBuffer[128];

that was mentioned in this discussion.

[jphickey]

I was responsible for making some of those size tweaks, and the reason is that newer GCC versions (e.g. 9+) are very aggressive about warning even the slightest possibility of a string truncation, even where the code handles the truncation perfectly fine.

Basically, the buffer has to get bigger at each step to accommodate the extra info added.

Nonetheless, this is the main risk of extending what seems like an unrelated buffer size - if it is copied or snprintf'ed into another buffer, then it might trigger a truncation warning where there was none before. Whatever change is made should be validated in either Ubuntu 20.04 or RHEL/CentOS 8 with BUILDTYPE=release to make sure it complies cleanly.

Perhaps these should all be converted to #define values in the header files to make it easier tweak in the future when needed.