Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #27619

Re: Source code static analysis tool recommendations

Subject Re: Source code static analysis tool recommendations
Newsgroups comp.arch.embedded
References (7 earlier) <p5a8to.4v4.1@stefan.msgid.phost.de> <fds3gtF1745U1@mid.dfncis.de> <p5bp9r$e0e$1@dont-email.me> <fdua92Fgm6rU1@mid.dfncis.de> <p5d85h$186$1@dont-email.me>
From Richard Damon <Richard@Damon-Family.org>
Message-ID <zAteC.15425$KA7.12251@fx05.iad> (permalink)
Organization Forte - www.forteinc.com
Date 2018-02-06 21:34 -0500

Show all headers | View raw

On 2/6/18 4:53 PM, David Brown wrote:
> On 06/02/18 19:25, Hans-Bernhard Bröker wrote:
>> Am 06.02.2018 um 09:34 schrieb David Brown:
>>> On 05/02/18 23:18, Hans-Bernhard Bröker wrote:
>>>> Am 05.02.2018 um 18:48 schrieb Stefan Reuther:
>>
>>>> Where on earth did you get that idea?  UINT32_C does not even _appear_
>>>> in the C99 standard.
>>
>>> 7.20.4 "Macros for integer constants" (assuming the section number is
>>> the same for C99 and C11, which is where I looked).
>>
>> C99 7.18.4.  Ah there it is.  Sorry, my bad for not finding that (or 
>> knowing about it off-hand).
>>
> 
> There aren't many in this newsgroup who could that section - remember, 
> this is the /practical/ group, not comp.lang.c !  And you are 
> technically right - "UINT32_C" does not appear anywhere, so you won't 
> find it be searching.  (For anyone who is interested enough to still be 
> reading, but not interested enough to look at the standards, the 
> paragraph talks about UINT/N/_C in general rather than UINT32_C in 
> particular.)
> 
>> But then Stefan's next statement is wrong.  There's no way this:
>>
>>  > expands to nothing on a 32-bit architecture...
>>
>> can be correct.  At the very least, UINT32_C(1) has to change the 
>> signedness of its constant argument, i.e. it has to expand to either 
>> of the following, or an equivalent:
>>
>>      (uint_least32_t)1
>>      1u
>>
>> And in both cases, both MISRA and PC-Lint _will_ accept that shift. 
>> Well, assuming the tool was configured correctly, that is.
> 
> <stdint.h> on my Linux system has:
> 
> /* Unsigned.  */
> # define UINT8_C(c)     c
> # define UINT16_C(c)    c
> # define UINT32_C(c)    c ## U
> # if __WORDSIZE == 64
> #  define UINT64_C(c)   c ## UL
> # else
> #  define UINT64_C(c)   c ## ULL
> # endif
> 
> 
> I would say that on a 32-bit system, UINT32_C has to include an 
> "unsigned" indication (like a cast, or adding a U suffix).  But since 
> there is no such thing in C as an integer constant of types smaller than 
> int or unsigned int, I can't decide if UINT16_C here should have the U 
> suffix or not.  I'm open to ideas either way - or we could punt it to 
> comp.lang.c for the opinions (at length) of people who sleep with the C 
> standards under the pillow, rather than just having a shortcut on their 
> desktop (like me).
> 

My thought is that since a uint8_t value or a uint16_t where int is 32 
bits, will promote to a signed int value, not making UINT8 or UINT16 
constants unsigned would be correct.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Source code static analysis tool recommendations John Speth <johnspeth@yahoo.com> - 2018-02-02 13:32 -0800
  Re: Source code static analysis tool recommendations George Neuner <gneuner2@comcast.net> - 2018-02-02 18:24 -0500
    Re: Source code static analysis tool recommendations John Speth <johnspeth@yahoo.com> - 2018-02-02 17:13 -0800
      Re: Source code static analysis tool recommendations George Neuner <gneuner2@comcast.net> - 2018-02-03 03:40 -0500
        Re: Source code static analysis tool recommendations Stefan Reuther <stefan.news@arcor.de> - 2018-02-03 11:45 +0100
        Re: Source code static analysis tool recommendations Grant Edwards <invalid@invalid.invalid> - 2018-02-03 16:37 +0000
          Re: Source code static analysis tool recommendations Stefan Reuther <stefan.news@arcor.de> - 2018-02-04 10:18 +0100
            Re: Source code static analysis tool recommendations Grant Edwards <invalid@invalid.invalid> - 2018-02-04 15:12 +0000
              Re: Source code static analysis tool recommendations Stefan Reuther <stefan.news@arcor.de> - 2018-02-05 18:48 +0100
                Re: Source code static analysis tool recommendations Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2018-02-05 23:18 +0100
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-06 09:34 +0100
                Re: Source code static analysis tool recommendations Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2018-02-06 19:25 +0100
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-06 22:53 +0100
                Re: Source code static analysis tool recommendations Richard Damon <Richard@Damon-Family.org> - 2018-02-06 21:34 -0500
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-07 09:06 +0100
                Re: Source code static analysis tool recommendations Jack <jack4747@gmail.com> - 2018-02-05 23:32 -0800
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-06 09:34 +0100
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-06 10:23 +0100
                Re: Source code static analysis tool recommendations Stefan Reuther <stefan.news@arcor.de> - 2018-02-06 19:05 +0100
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-06 23:02 +0100
                Re: Source code static analysis tool recommendations Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2018-02-07 02:02 +0100
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-07 09:21 +0100
                Re: Source code static analysis tool recommendations Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2018-02-08 00:57 +0100
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-08 10:46 +0100
                Re: Source code static analysis tool recommendations Stefan Reuther <stefan.news@arcor.de> - 2018-02-07 20:04 +0100
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-07 20:54 +0100
                Re: Source code static analysis tool recommendations Stefan Reuther <stefan.news@arcor.de> - 2018-02-08 18:58 +0100
                Re: Source code static analysis tool recommendations David Brown <david.brown@hesbynett.no> - 2018-02-09 09:17 +0100
                Re: Source code static analysis tool recommendations Clifford Heath <no.spam@please.net> - 2018-02-10 20:55 +1100
                Re: Source code static analysis tool recommendations Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2018-02-10 19:59 -0500
                Re: Source code static analysis tool recommendations Clifford Heath <no.spam@please.net> - 2018-02-10 20:49 +1100

csiph-web