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

Groups > comp.arch.embedded > #27616

Re: Source code static analysis tool recommendations

From David Brown <david.brown@hesbynett.no>
Newsgroups comp.arch.embedded
Subject Re: Source code static analysis tool recommendations
Date 2018-02-06 22:53 +0100
Organization A noiseless patient Spider
Message-ID <p5d85h$186$1@dont-email.me> (permalink)
References (6 earlier) <p577t1$o54$1@reader2.panix.com> <p5a8to.4v4.1@stefan.msgid.phost.de> <fds3gtF1745U1@mid.dfncis.de> <p5bp9r$e0e$1@dont-email.me> <fdua92Fgm6rU1@mid.dfncis.de>

Show all headers | View raw

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).

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