Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #27621
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: Source code static analysis tool recommendations |
| Date | 2018-02-07 09:06 +0100 |
| Organization | A noiseless patient Spider |
| Message-ID | <p5ec24$cf4$1@dont-email.me> (permalink) |
| References | (8 earlier) <fds3gtF1745U1@mid.dfncis.de> <p5bp9r$e0e$1@dont-email.me> <fdua92Fgm6rU1@mid.dfncis.de> <p5d85h$186$1@dont-email.me> <zAteC.15425$KA7.12251@fx05.iad> |
On 07/02/18 03:34, Richard Damon wrote: > 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. Yes, I agree with that logic. Then it will be "an integer constant expression corresponding to the type uint_leastN_t", in that you will get the same behaviour for the expression "u + x" for any x, when u is either: uint8_t u = 1; or #define u UINT8_C(1) But you can also say that by adding a U, you turn the constant into type "unsigned int" rather than "int", and thus it will not be promoted to a signed int. I don't know if the standards are clear enough here to require one interpretation or the other. The gcc implementations I have looked at (some with glibc for Linux, some with newlib for embedded ARM) all follow the first version with no U for sizes less than an "int". An older CodeWarrior with its EWL library seems to take the other version and add a U. Based purely on "which of these to I trust more to understand the standards", my vote will be with gcc/glibc/newlib - the CodeWarrior C99 support and library has never impressed me with its quality.
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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