Fix build failures on RTEMS

[skliper]

There are two issues that cause a build failure when using a recent RTEMS toolchain/library:

• {{{MSG_DONTWAIT}}} now //is// defined by the library headers. This is re-defined in {{{fsw/cfe-core/src/inc/network_includes.h}}} - possibly an older library did not define this?

• {{{putchar()}}} is a defined as a macro, but the {{{fsw/cfe-core/unit-test/osprintf_priv.h}}} file has a function prototype for this which conflicts. This function prototype really should not be here.

[skliper]

Imported from trac issue 79. Created by jphickey on 2015-07-10T16:49:10, last modified: 2019-03-05T14:57:55

[skliper]

Trac comment by jphickey on 2015-07-10 16:56:16:

Pushed commit [changeset:33e7b99] which addresses these issues.

[skliper]

Trac comment by jphickey on 2015-07-15 13:57:03:

== REBASED COMMIT ==

This has been rebased to the {{{development}}} baseline approved at the 2015-07-14 CCB

New commit ID: [changeset:8f15bc7]

[skliper]

Trac comment by sstrege on 2015-07-24 17:11:32:

Approve

[skliper]

Trac comment by glimes on 2015-07-27 12:53:53:

Approve.

''Even without having an RTEMS build environment handy, I can confirm that it is generally very bad practice to plant an extern declaration for any standard function -- putchar() and getchar() especially as these are historically implemented using macros.''

[skliper]

Trac comment by sduran on 2015-07-27 17:49:18:

Approve, but that putchar() should have had a #ifdef CFE_ARINC653 around it. It needs to be there for building for ARINC653 (which does not have a put char). Need to add back with the #ifdef.

[skliper]

Trac comment by glimes on 2015-07-28 10:55:33:

Really not a fan of #ifdef.

Any way to tuck this into a header in an RTEMS specific directory, so that code that is not specific to RTEMS never has to care that we have to jump through extra hoops on RTEMS to use a standard facility?

[skliper]

Trac comment by jphickey on 2015-07-28 12:24:42:

To clarify - it is not RTEMS that requires special hoops, it is ARINC653. RTEMS has an implementation of the standard putchar() function so there is no issue with this platform. It is special sauce that was added to support ARINC653 that is //breaking// the build for any other C library that happens to implement putchar as a macro - RTEMS being the first/prime example, but this is quite common for I/O primitives to be macros in lightweight C libraries.

In doing this change, I grepped through the code, and the only place putchar() was being called was in the osprintf.c and ut_osprintf_stubs.c inside the OS_OutputSingleChar() function.

Here is what I found:

• Although named as a "stub", ut_osprintf_stubs.c is basically a copy of osprintf.c that still has full functionality. There are some differences between the files for some reason (don't know the history here).
• The calls to putchar() within the implementation is //also// conditional on #ifdef OSP_ARINC653_CFE, and when this is defined TUTF_putchar() is called instead of putchar().
• Both the ut and non-ut versions of this osprintf implementation have the override to call TUTF_putchar() instead of putchar(). As best I can tell, if OSP_ARINC653_CFE is defined, then only TUTF_putchar() is ever used - putchar() is NOT used, even if using the embedded printf code on ARINC653.
• Nowhere else in the source tree is putchar() //or// TUTF_putchar() ever actually implemented. So this cannot possibly link on ARINC653 using the source code that exists within the CFE distribution today. Is there something else missing here?

To summarize:

1. I am just failing to see a real problem here - the one platform that supposedly needs the putchar() prototype is actually using TUTF_putchar() in both cases, unless there is other code out there that is not yet in the official source tree?
2. Other issues/problems with the embedded osprintf code aside, the preferred approach would be to call it something //other than putchar()// so as to not conflict in case the C library actually does supply this function/macro (the vast majority of them will, as it is standardized).

This way the ARINC653 BSP can implement this function and not have any conflicts.

Other platform BSPs that //do// have stdio but for some reason also want to use the embedded printf can just supply a wrapper which calls the supplied putchar() (although I'm still confused as to why one would want this, you could do it).

[skliper]

Trac comment by glimes on 2015-08-10 16:38:07:

Approve [changeset:8f15bc7] (remove spurious putchar() prototype and only define MSG_DONTWAIT if it is not already defined).

[skliper]

Trac comment by glimes on 2015-08-25 14:57:17:

merged into ic-2015-08-10 promoted to development 25 Aug 2015

[skliper]

Trac comment by glimes on 2016-02-16 13:16:45:

Susie confirmed these tickets have been approved for CFE 6.5

[skliper]

Trac comment by jhageman on 2019-03-05 14:57:55:

Milestone renamed