Notice: We have migrated to GitLab launching 2024-05-01 see here: https://gitlab.rtems.org/

Changes between Initial Version and Version 1 of Ticket #3800, comment 11


Ignore:
Timestamp:
05/05/20 04:08:25 (4 years ago)
Author:
Chris Johns
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #3800, comment 11

    initial v1  
    1 I am attempting to follow the flow of this ticket to see what the issue is. Sebastian, Joel pushed the patch on 2 Oct 2019, then you updated the ticket with comment:4 around Feb 1 2020 plus a patch to fix the change Joel pushed removing references to one of the enum values. The change only updated the ticket. It was confusing for me to determining the status and action that needs to happen. I have now taken the time to do time.
     1I am attempting to follow the flow of this ticket to see what the issue is. Sebastian, Joel pushed the patch on 2 Oct 2019, then you updated the ticket with comment:4 around Feb 1 2020 plus a patch to fix the change Joel pushed removing references to one of the enum values. The change only updated the ticket. It was confusing for me to determining the status and action that needs to happen. I have now taken the time to do this.
    22
    3 In regards to `enum`s one of the fixes for ticket #3969 highlights a subtle issue with `bool` as a return type then changing code to need more return values. There is no upgrade path I consider **clean** or **safe** (?) if there is a need to add more return states than a `bool`'s true and false. The `libdl` ticket shows what happens if you move to an `enum` from `bool` as compilers, coverity etc cannot see enough to know any code that was `if (!returned_bool_now_enum()) ...` maybe wrong. In the case of `libdl` the `true` or `1` became `.*_no_error` and `0` so a valid or no error result was incorrectly handled in code not updated. I think in important interfaces an `enum` should be considered desirable even if there is only two states and even if only one state is currently being used, i.e. what we now have.
     3In regards to `enum`'s one of the fixes for ticket #3969 highlights a subtle issue with `bool` as a return type then changing code to need more return values. There is no upgrade path I consider **clean** or **safe** (?) if there is a need to add more return states than a `bool`'s true and false. The `libdl` ticket shows what happens if you move to an `enum` from `bool` as compilers, coverity etc cannot see enough to know any code that was `if (!returned_bool_now_enum()) ...` maybe wrong. In the case of `libdl` the `true` or `1` became `.*_no_error` and `0` so a valid or no error result was incorrectly handled in code not updated. I think in important interfaces an `enum` should be considered desirable even if there is only two states and even if only one state is currently being used, i.e. what we now have.
    44
    55I agree the documentation should indicate how to use the `enum` results returned. Can someone please update the enum's comments so a user knows how to handle them if returned?