Re: uint32_t typedef differences causes issues


Benjamin Walsh <benjamin.walsh@...>
 

On Tue, Jan 24, 2017 at 10:57:21AM -0500, Anas Nashif wrote:
On Fri, Jan 20, 2017 at 7:09 AM, Szymon Janc <ext.szymon.janc(a)tieto.com>
wrote:

Hi,

On Fri, Jan 20, 2017 at 12:21 PM, Anas Nashif <nashif(a)gmail.com> wrote:



On Fri, Jan 20, 2017 at 5:26 AM, Marcus Shawcroft <
marcus.shawcroft(a)gmail.com> wrote:

On 20 January 2017 at 04:06, Kumar Gala <kumar.gala(a)linaro.org> wrote:

As Anas said, I don’t think we can expect 3rd party software to
utilize PRIu32. The fact that newlib and minimal libc different in the way
the typedef (u)int32_t seems like a pointless difference for us to maintain
and have to deal with a lot of pain if one switches between them.

This is not a choice between alternatives. There are two separate
decisions here:

1) Do we align minimal C with newlib in order to have consistent
breakage in /ext irrespective of the users choice between newlib and
minimal lib.

2) Do we write portable conforming code in our own tree outside of
/ext using the standards defined PRI macros.


We can do both, they are not alternatives:
- Number 2 is valuable because writing portable code leaves our
options open in the future.
- Number 1 is valuable because it will ensure consistent breakage under
/ext.

Ironically, that said, not doing 1) helps with 2) because it flushes
out broken code.

But either way, whether or not we do 1) I strongly advocate that for
our own code we adopt 2).

That sounds reasonable to me. Change minimal libc to align with newlib
and apply 2, the question is if we want to enforce usage of PRI macros.

A bit off topic, but could someone shed some light on why Zephyr has
support for two libc implementations?
ie Why not just always use newlib ?
The reason why we have minimal libc... it did the job for a basic kernel
implementation and mostly was used only for testing the kernel internals.
It is also a control we have (had), making sure the kernel does not rely on
libc functions and is self-contained. There is lots of history behind that,
probably Ben can add to this :-)
That's basically it.

IMHO, I think that this reasoning was bogus anyway, and only meant we
had (probably worse) re-implementation of some libc routines, with
different names, or not. :-/

Over the last 2 years I have seen developers implement clones of libc
functions to overcome the lack of support of those functions in the minimal
libc. We have been adding libc function on individual basis, sometimes
pulling those functions from different sources creating a frankenstein libc
implementation that will be difficult to maintain going forward.

Given that the zephyr project now is more than just a kernel and that any
application based on Zephyr will most likely want to use newlib anyways, I
do not think there is a reason why we should continue using minimal libc as
the default, we need however to keep an eye on usage of libc functions
inside the kernel and monitor the footprint (ram and rom) if we follow this
approach.
+1.

Join devel@lists.zephyrproject.org to automatically receive all group messages.