<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>LPCXpresso IDEのトピックDifference in uint32_t between Redlib and newlib causes Eclipse CDT code analyser to misbehave</title>
    <link>https://community.nxp.com/t5/LPCXpresso-IDE/Difference-in-uint32-t-between-Redlib-and-newlib-causes-Eclipse/m-p/565411#M17983</link>
    <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;STRONG&gt;Content originally posted in LPCWare by OldManVimes on Sat Feb 21 03:35:40 MST 2015&lt;/STRONG&gt;&lt;BR /&gt;&lt;SPAN&gt;Hi support,&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;My LPCXpresso (7.4.0) workspace contains 2 MCU projects. One using Redlib (LPC1200) and the other using newlib (LPC1700) (not NewLibNano).&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;These projects have several source files with the same name (not sure whether this is relevant, but it does not hurt to mention).&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;In Redlib, uint32_t is an unsigned int (defined in stdint.h)&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;In Newlib, uint32_t is a __UINT32_TYPE__ which (according to the CDT) expands to "long unsinged int" (defined in _default_types.h). I guess __UINT32_TYPE__ is a compiler built-in macro.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Since we are dealing with a 32-bit CPU, the binary difference between the two is zero. So far so good.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;In my Redlib project a printf of a uint32_t looks like:&lt;/SPAN&gt;&lt;BR /&gt;&lt;TABLE border="1"&gt;&lt;TBODY&gt;&lt;TR&gt;&lt;TD bgcolor="#cacaca"&gt; &lt;PRE&gt;uint32_t foo = 42; // unsigned int
printf ("foo: %u\n", foo);&lt;/PRE&gt; &lt;/TD&gt;&lt;/TR&gt;&lt;/TBODY&gt;&lt;/TABLE&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;In newlib it is:&lt;/SPAN&gt;&lt;BR /&gt;&lt;TABLE border="1"&gt;&lt;TBODY&gt;&lt;TR&gt;&lt;TD bgcolor="#cacaca"&gt; &lt;PRE&gt;uint32_t foo = 42; // long unsigned int
printf ("foo: %lu\n", foo);&lt;/PRE&gt; &lt;/TD&gt;&lt;/TR&gt;&lt;/TBODY&gt;&lt;/TABLE&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;There are 2 issues:&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;1. This is annoying since it is essentially the same source file, but the format string must differ because there is a type mismatch between the two library sets.&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;2. The eclipse code analyser (so not the compiler!) gets confused and starts complaining about the format strings.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;I can solve problem 1 by ditching Redlib for Newlib nano, or by using those horrible PRIu32 style macros, but I would prefer not to.&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;Problem 2 is really weird, because I can get it to behave again by rebuilding the index. However the required activities are vague. Sometimes I can get it to work, and other times I cannot.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;So here are my questions:&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;1. Why are there differences in the types? Can you (provide an option to) harmonize them in a future release?&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;2. Why does the CDT indexer / code analyser get confused and what can I do to (short of disabling the CODAN setting) prevent that from happening?&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Kind regards,&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;Vimes&lt;/SPAN&gt;&lt;BR /&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
    <pubDate>Wed, 15 Jun 2016 22:22:47 GMT</pubDate>
    <dc:creator>lpcware</dc:creator>
    <dc:date>2016-06-15T22:22:47Z</dc:date>
    <item>
      <title>Difference in uint32_t between Redlib and newlib causes Eclipse CDT code analyser to misbehave</title>
      <link>https://community.nxp.com/t5/LPCXpresso-IDE/Difference-in-uint32-t-between-Redlib-and-newlib-causes-Eclipse/m-p/565411#M17983</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;STRONG&gt;Content originally posted in LPCWare by OldManVimes on Sat Feb 21 03:35:40 MST 2015&lt;/STRONG&gt;&lt;BR /&gt;&lt;SPAN&gt;Hi support,&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;My LPCXpresso (7.4.0) workspace contains 2 MCU projects. One using Redlib (LPC1200) and the other using newlib (LPC1700) (not NewLibNano).&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;These projects have several source files with the same name (not sure whether this is relevant, but it does not hurt to mention).&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;In Redlib, uint32_t is an unsigned int (defined in stdint.h)&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;In Newlib, uint32_t is a __UINT32_TYPE__ which (according to the CDT) expands to "long unsinged int" (defined in _default_types.h). I guess __UINT32_TYPE__ is a compiler built-in macro.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Since we are dealing with a 32-bit CPU, the binary difference between the two is zero. So far so good.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;In my Redlib project a printf of a uint32_t looks like:&lt;/SPAN&gt;&lt;BR /&gt;&lt;TABLE border="1"&gt;&lt;TBODY&gt;&lt;TR&gt;&lt;TD bgcolor="#cacaca"&gt; &lt;PRE&gt;uint32_t foo = 42; // unsigned int
printf ("foo: %u\n", foo);&lt;/PRE&gt; &lt;/TD&gt;&lt;/TR&gt;&lt;/TBODY&gt;&lt;/TABLE&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;In newlib it is:&lt;/SPAN&gt;&lt;BR /&gt;&lt;TABLE border="1"&gt;&lt;TBODY&gt;&lt;TR&gt;&lt;TD bgcolor="#cacaca"&gt; &lt;PRE&gt;uint32_t foo = 42; // long unsigned int
printf ("foo: %lu\n", foo);&lt;/PRE&gt; &lt;/TD&gt;&lt;/TR&gt;&lt;/TBODY&gt;&lt;/TABLE&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;There are 2 issues:&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;1. This is annoying since it is essentially the same source file, but the format string must differ because there is a type mismatch between the two library sets.&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;2. The eclipse code analyser (so not the compiler!) gets confused and starts complaining about the format strings.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;I can solve problem 1 by ditching Redlib for Newlib nano, or by using those horrible PRIu32 style macros, but I would prefer not to.&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;Problem 2 is really weird, because I can get it to behave again by rebuilding the index. However the required activities are vague. Sometimes I can get it to work, and other times I cannot.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;So here are my questions:&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;1. Why are there differences in the types? Can you (provide an option to) harmonize them in a future release?&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;2. Why does the CDT indexer / code analyser get confused and what can I do to (short of disabling the CODAN setting) prevent that from happening?&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Kind regards,&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;Vimes&lt;/SPAN&gt;&lt;BR /&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 15 Jun 2016 22:22:47 GMT</pubDate>
      <guid>https://community.nxp.com/t5/LPCXpresso-IDE/Difference-in-uint32-t-between-Redlib-and-newlib-causes-Eclipse/m-p/565411#M17983</guid>
      <dc:creator>lpcware</dc:creator>
      <dc:date>2016-06-15T22:22:47Z</dc:date>
    </item>
    <item>
      <title>Re: Difference in uint32_t between Redlib and newlib causes Eclipse CDT code analyser to misbehave</title>
      <link>https://community.nxp.com/t5/LPCXpresso-IDE/Difference-in-uint32-t-between-Redlib-and-newlib-causes-Eclipse/m-p/565412#M17984</link>
      <description>&lt;HTML&gt;&lt;HEAD&gt;&lt;/HEAD&gt;&lt;BODY&gt;&lt;STRONG&gt;Content originally posted in LPCWare by lpcxpresso-support on Mon Feb 23 03:33:55 MST 2015&lt;/STRONG&gt;&lt;BR /&gt;&lt;SPAN&gt;We'll investigate this difference between Newlib and Redlib.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Note that issue 1) is actually not an error. Newlib provides some format checking of the parameters to printf, and these are generating a warning if you use the %u format string instead of %lu. It should be possible to disable this checking using the -Wno-format option.&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;Regards,&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;LPCXpresso Support&lt;/SPAN&gt;&lt;BR /&gt;&lt;/BODY&gt;&lt;/HTML&gt;</description>
      <pubDate>Wed, 15 Jun 2016 22:22:48 GMT</pubDate>
      <guid>https://community.nxp.com/t5/LPCXpresso-IDE/Difference-in-uint32-t-between-Redlib-and-newlib-causes-Eclipse/m-p/565412#M17984</guid>
      <dc:creator>lpcware</dc:creator>
      <dc:date>2016-06-15T22:22:48Z</dc:date>
    </item>
  </channel>
</rss>

