[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
root.
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