[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [gpsd-dev] Warnings on 32 bit Fedora 24

From: Fred Wright
Subject: Re: [gpsd-dev] Warnings on 32 bit Fedora 24
Date: Sat, 23 Jul 2016 13:32:06 -0700 (PDT)

No subject garble this time, so it must have been the funny character.

On Fri, 22 Jul 2016, Hal Murray wrote:

> I don't understand the left shift stuff.  I'm surprised you haven't seen it
> and fixed it.

I personally think the C standard is being overly pedantic in this area.
Ostensibly it's about avoiding possible overflow traps, but there are
various other integer overflow cases that C allows (while blithely
ignoring).  Consider:

        -1LL * (1 << wid)

> --------
> There is another mess in this area.  Why is scons rebuilding a lot of stuff
> when I install?

I think I's seen that as well, but didn't investigate.  Though scons does
have a "tell me why you're rebuilding these things" option.

> My work flow is to do a git pull on one machine then rsync the bits without
> the git overhead to various other systems.  At one point, I thought scons was
> rebuilding stuff to get the current version that it couldn't get from git.
> But it looks like it's rebuilding a lot more than that.  Mumble.  I haven't
> looked carefully recently.

One thing to be aware of, though it doesn't seem to be applicabe in this
case, is that whenever the version has "-dev" in it, the current git
commit ID is incorporated into the version.  Thus any new commit triggers
a rebuild of anything that depends on the version string.

> Am I being unreasonable when I expect scons install to not rebuild anything
> if I have already done a build and check?

No, but one possibility is discrepancies between root and non-root
environments.  Presumably you're building as non-root and installing as

BTW, building as root and then later trying to build as non-root can be a
complete mess, since some of scons's internal files wind up being owned by
root and not modifiable by the non-root build.

On Fri, 22 Jul 2016, Greg Troxel wrote:

> except that this won't work for width 32.   So instead this could be
>   fld &=  ~(~0ULL << width)

In general I think it's cleaner to write "all ones" as ~0 rather than as
-1, especially when the result is intended to be unsigned.

Strictly speaking, that's a portability requirement, given that C doesn't
demand a twos-complement processor, but I suspect that all the real-world
C code that works correctly on a non-twos-complement processor could be
written on the head of a pin.  And although the original UNIX was written
for a ones-complement processor, I don't think there was ever a PDP-7 C.

Fred Wright

reply via email to

[Prev in Thread] Current Thread [Next in Thread]