[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [gpsd-dev] C99 Aftermath
Gary E. Miller
Re: [gpsd-dev] C99 Aftermath
Mon, 5 Sep 2016 20:25:40 -0700
On Mon, 5 Sep 2016 19:46:45 -0700 (PDT)
Fred Wright <address@hidden> wrote:
> On Mon, 5 Sep 2016, Gary E. Miller wrote:
> > On Mon, 5 Sep 2016 18:04:13 -0700 (PDT)
> > Fred Wright <address@hidden> wrote:
> > > On Mon, 5 Sep 2016, Gary E. Miller wrote:
> > > >
> > > [...]
> > > > What I would like is the C99 stuff be guarded by #ifdef
> > > > __linux__. Then at least the Linux code can be clean.
> > >
> > > In this context, "clean" means "compatible with some hypothetical
> > > future compiler that demands C99 compliance with no
> > > alternative".
> > Not to mean, clean maens that hypothetical future patches break C99
> > and POSIX 2001 compliance by accident.
> But forcing C99 on Linux means that anything that breaks *non-C99*
> compatibility will be hidden on Linux. Ideally the code should be
> tested both ways. Perhaps it should be a build option.
Lost me. By definition gpsd strives for C99 or better. All this is
doing is raising warnings on pre-C99 stuff that was removed in C99.
> > Yes, there was, but since it is now done, let us not throw away
> > that work.
> Well it's not entirely clear that what was already done was done in
> the best possible way (at least where it involved fiddling with
> feature-test flags), and figuring that out *does* take some work.
Of course it was not done to the besst possible way. The build famr
showed that right away. But for Linux it was a big lap forward. Let us
not lose that work.
> > Sadly, only one, Linux. So just hard code it.
> I mean for testing, and that works on any platform with a "c99"
I also mean for testing. You thin we should just tell the compiler to
stop warnings because they are just for testing?
> > I took a quick look, Not a long enough look to apply them yet, and
> > since we are still debating the first one I'll not do it yet.
> > I think the patches might be in the wrong order. You seem to be
> > reverting fixes before fixing the issue. Which will might break
> > git-bisect. Are you sure you order is correct?
> First of all, I hope you're looking at the patch numbers in the
> subject lines rather than the order in the mailbox.
They are the same to me. And I will be applying them in a different order
> As I explained in my original email, the very first patch in the set
> reverts everything except the commits that I intended to keep
Right, I understood you, and I once again disagree. We need to keep the
good parts. I see a lot in patch #1 I don;t like, but I think I see
a way that will make us bot happy. Since you don't get what I'm saying,
I'll just be doing it Tuesday, maybe Wednesday.
> I didn't want to mix up intracommit edits with the big
> revert (though I did have to fix one conflict).
And I do not want a big revert. You are throwing the baby out with the
bath water, just because I have not finished it yet does not mean it
will not go forward.
> Indeed git-bisect is somewhat broken for this stuff,
Yeah, so let us not break it more.
> BTW, that's also why any reintroduction of something to actually
> force C99 mode should only happen *after* this set of patches.
We'll just have to agree to disagree. But we can agree it needs to be
wrapped up this week. Been a while since a release, and some good stuff
in git head that needs to get out to the world.
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
address@hidden Tel:+1 541 382 8588
Description: OpenPGP digital signature