Closed skliper closed 4 years ago
Imported from trac issue 77. Created by jphickey on 2015-07-09T13:17:14, last modified: 2019-03-05T14:57:55
Trac comment by jphickey on 2015-07-09 16:39:47:
Pushed commit [changeset:67b87ef] for review
Trac comment by jphickey on 2015-07-09 16:46:15:
This is included in the {{{ic-2015-07-14}}} integration candidate for testing
Trac comment by glimes on 2015-07-13 14:52:00:
Accept.
Trac comment by jphickey on 2015-07-17 10:49:40:
CCB did not get to review this change set during the 2015-07-14 review -- this is deferred to the next review on 7/28...
Trac comment by sstrege on 2015-07-24 16:59:50:
Approve/Accept changes to cfe_es_perf.c
Request to keep the CFE_MAKE_BIG16 macro definition in ccsds.h for backward compatibility with the default tables in the SC and SCH applications.
Trac comment by sduran on 2015-07-27 17:43:08:
Accept, agree with Susie on keeping BIG16 macro for now.
Trac comment by jphickey on 2015-07-28 17:25:19:
Per comments above, pushed commit [changeset:b17c45c] which reverts the removal of CFE_MAKE_BIG16() macro.
This will be merged into the next ic-ccb-review
branch for consideration during the next CCB review on 2015-08-10.
Trac comment by jwilmot on 2015-08-10 14:46:58:
Accept
Trac comment by glimes on 2015-08-25 14:56:16:
merged into ic-2015-08-10 promoted to development 25 Aug 2015
Trac comment by glimes on 2016-02-16 13:16:45:
Susie confirmed these tickets have been approved for CFE 6.5
Trac comment by jhageman on 2019-03-05 14:57:55:
Milestone renamed
Any usage of SOFTWARE_BIG/LITTLE_BIT_ORDER is an indicator of a problem area as code is ported to additional platforms. Code should be written endian-neutral wherever possible.
The {{{SOFTWARE_BIG_BIT_ORDER}}} and {{{SOFTWARE_LITTLE_BIT_ORDER}}} are not reliable, as they assume this value based on the BSP type but that is not always correct. For instance, the pc-linux BSP assumes SOFTWARE_LITTLE_BIT_ORDER but in fact that BSP is also fully applicable to big-endian platforms running linux as well. Some architectures (MIPS, ARM, etc) have both big- and little- endian modes of operation which further invalidates this macro.
In fact the C standard does not specify any portable way to determine endianness at //compile time//, however runtime checks using a union are fairly easy and reasonably portable where it is absolutely necessary to do something different.