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

Groups > comp.arch.embedded > #27612

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 09:34 +0100
Organization A noiseless patient Spider
Message-ID <p5bpat$e0e$2@dont-email.me> (permalink)
References (4 earlier) <p54og4$a65$1@reader2.panix.com> <p56mkp.2a0.1@stefan.msgid.phost.de> <p577t1$o54$1@reader2.panix.com> <p5a8to.4v4.1@stefan.msgid.phost.de> <b23bdedf-ecb4-4a06-87c7-8e134020af1d@googlegroups.com>

Show all headers | View raw

On 06/02/18 08:32, Jack wrote:
> Il giorno lunedì 5 febbraio 2018 18:59:12 UTC+1, Stefan Reuther ha scritto:
>> Am 04.02.2018 um 16:12 schrieb Grant Edwards:
>>> On 2018-02-04, Stefan Reuther <stefan.news@arcor.de> wrote:
>>>> What I find more annoying is that MISRA finds this
>>>>
>>>>      uint32_t MASK = UINT32_C(1) << 17;
>>>>
>>>> objectionable. '1', no matter how spelled, has type 'char' for MISRA,
>>>> and cannot be shifted by 17 bits.
>>>
>>> In MISRA C, the literal 1 is a char not an int?
>>
>> Yes. MISRA C 6.10.4 "Underlying type".
>>
>> The problem they're trying to solve isn't too far-fetched: if 'int' has
>> 16 bits only, '1 << 17' is undefined, so you'd better be explicit about
>> the type you're shifting. The problem now is that C99's way of being
>> explicit is the 'UINT32_C' macro - but that one expands to nothing on a
>> 32-bit architecture...
>>
>>
>>   Stefan
> 
> If you write "1ul" it should be 32 bits.
> 

No - it should be /at least/ 32 bits.  On 64-bit Linux, it will be 64 bits.

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