[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] ARM port problem in rtcm3.2 handling
From: |
Eric S. Raymond |
Subject: |
Re: [gpsd-dev] ARM port problem in rtcm3.2 handling |
Date: |
Thu, 21 Apr 2016 23:11:36 -0400 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
Hal Murray <address@hidden>:
> address@hidden said:
> >> > I had been thinking that since fiexed width type (uint88_t, etc.)
> >> > are in C99 we should use those instead. But I see in C99 7.1.1.1 3
> >> > that fixed width types are optional. I don't recall that ever
> >> > causing us trouble.
> >> So what do I do if I want a signed 8 bit int? How would you have fixed
> this
> >> if the ARM was wrong?
>
> I just poked around and learned that there are "signed char"s. Somehow, I
> don't remember ever running into them before. That answers my question
> above.
You're not being forgetful or oblivious. It's pretty freakin' rare
for anyone to explicitly declare a signed char, so much so that I'm
not surprised you've never seen it done before.
> > They're optional in C99 but not in POSIX-2001 and descendants. It's been at
> > least a decade since anyone shipped a C or C++ compiler without them. We're
> > considering them save for NTPsec; GPSD can, too.
>
> My take from this is that "char" without a modifier is evil.
> Unfortunately, it's used all over the place, starting with string
> literals.
Yeah, because it's not a problem there. It only becomes an issue when the
char value is assigned to a short or int and might get sign-extended.
Good practice, which NTPsec aims to follow, is to (a) always and only
use char when the storage is semantically a char and never assigned to
or from a numeric scalar variable, (b) always and only use int8_t or
uint8_t when you want an 8-bit quantity to be interpreted as numeric,
and (c) never use "signed char" or "unsigned char".
(The 2 "signed char" exceptions are unit test framework code that's
not ours; there might be some remnant "unsigned char"s in ancient
header declarations, but I think I fixed them all.)
The GPSD code hasn't had quite as thorough a POSIX makeover, but the few
signed chars that are there have been static checked by both Coverity
and splint.
> Are there any static code checking tools that check for it? If so,
> what do they actually check for?
Possible sign-extension bugs. This is easy to do with elementary
assignment-graph coloring - both Coverity and Splint do it.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
- Re: [gpsd-dev] ARM port problem in rtcm3.2 handling, (continued)
- Re: [gpsd-dev] ARM port problem in rtcm3.2 handling, Gary E. Miller, 2016/04/20
- Re: [gpsd-dev] ARM port problem in rtcm3.2 handling, Eric S. Raymond, 2016/04/20
- Re: [gpsd-dev] ARM port problem in rtcm3.2 handling, Paul Fertser, 2016/04/21
- Re: [gpsd-dev] ARM port problem in rtcm3.2 handling, Gary E. Miller, 2016/04/21
- Re: [gpsd-dev] ARM port problem in rtcm3.2 handling, Hal Murray, 2016/04/21
- Re: [gpsd-dev] ARM port problem in rtcm3.2 handling, Gary E. Miller, 2016/04/21
- Re: [gpsd-dev] ARM port problem in rtcm3.2 handling, Eric S. Raymond, 2016/04/21
- Re: [gpsd-dev] ARM port problem in rtcm3.2 handling, Hal Murray, 2016/04/21
- Re: [gpsd-dev] ARM port problem in rtcm3.2 handling,
Eric S. Raymond <=
- Re: [gpsd-dev] ARM port problem in rtcm3.2 handling, Gary E. Miller, 2016/04/21