Fix #390, #392, osal select API unit tests and fixes

[CDKnightNASA]

Describe the contribution
fixes #390, fixes #392 -- adds unit tests for OSAL select API

Partially addresses #377, but full solution is a functional test that includes an operational scenario (actually select on a resource, confirm it pends until that resource is available).. bonus points if it illustrates the differences between OS's so it's clear from a user perspective what will work and what wont.

Testing performed
Built unit tests, tests passed.

Expected behavior changes
Externalizes enum for SelectSingle, ensures that pointers passed to SelectFd...() APIs are not null, ensures that pointer to SelectSingle is not null.

System(s) tested on
Debian 9

Contributor Info - All information REQUIRED for consideration of pull request
Christopher.D.Knight@nasa.gov

[skliper]

Note this doesn't actually address #377, I probably didn't do a good job describing the issue. The "functional tests" that are missing are the ones similar to those in src/tests which don't use mocks/stubs. The functional tests needed for #377 are against the API, and should demonstrate the functions work as intended.

The tests here are the "coverage test" part of unit tests.

[skliper]

The changes here are good, but shouldn't mark #377 as fixed (see my other comment).

Nitpick - preference would be to separate flight code changes and unit test changes into separate commits

[CDKnightNASA]

The changes here are good, but shouldn't mark #377 as fixed (see my other comment).

Nitpick - preference would be to separate flight code changes and unit test changes into separate commits

Note this doesn't actually address #377, I probably didn't do a good job describing the issue. The "functional tests" that are missing are the ones similar to those in src/tests which don't use mocks/stubs. The functional tests needed for #377 are against the API, and should demonstrate the functions work as intended.

The tests here are the "coverage test" part of unit tests.

No these do not use stubs, they do confirm the functional behavior of the Select API.

[CDKnightNASA]

The changes here are good, but shouldn't mark #377 as fixed (see my other comment).

Nitpick - preference would be to separate flight code changes and unit test changes into separate commits

Wait, I'm sure I've been told to commit tests when I commit flight code... :D

I can certainly re-split-out the null pointer check and enum move if the CCB would prefer as a separate pull. I did give a heads-up at last CCB that I would do a pull request incorporating all changes together, and heard no objections.

[skliper]

The changes here are good, but shouldn't mark #377 as fixed (see my other comment).
Nitpick - preference would be to separate flight code changes and unit test changes into separate commits

Wait, I'm sure I've been told to commit tests when I commit flight code... :D

I can certainly re-split-out the null pointer check and enum move if the CCB would prefer as a separate pull. I did give a heads-up at last CCB that I would do a pull request incorporating all changes together, and heard no objections.

Not a separate pull request, just separate commits. I have to work on explaining what's in my head. Another concept I describe poorly is "one topic per commit"... and grouping commits in a pull request.

[skliper]

Really just a nit in this case since the changes are very easy to review, straight forward, etc. More complex changes where there's documentation, unit tests, flight code, etc my preference is smaller commits group into a single pull request. Probably useful information for a contributor's guide...

[skliper]

The changes here are good, but shouldn't mark #377 as fixed (see my other comment).
Nitpick - preference would be to separate flight code changes and unit test changes into separate commits

Note this doesn't actually address #377, I probably didn't do a good job describing the issue. The "functional tests" that are missing are the ones similar to those in src/tests which don't use mocks/stubs. The functional tests needed for #377 are against the API, and should demonstrate the functions work as intended.
The tests here are the "coverage test" part of unit tests.

No these do not use stubs, they do confirm the functional behavior of the Select API.

Worth a discussion at the CCB... I didn't immediately see where it shows that the select blocks as it's supposed to until a file becomes readable or writable, or a demonstration of the timeout and verification of reasonable timing.

[jphickey]

Should note that RTEMS doesn't really support select on bare files, the underlying system call only works on sockets. It isn't a limitation of OSAL, its a limitation of the OS. Therefore any functional test for select should focus on its use with sockets rather than files.

[skliper]

CCB 20200415 - APPROVED