Re: [gpsd-dev] C99 Aftermath

[Gary E. Miller]

Yo Fred!

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"
> command.

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
than you.

> As I explained in my original email, the very first patch in the set
> reverts everything except the commits that I intended to keep
> verbatim.

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.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        address@hidden  Tel:+1 541 382 8588

pgpodownRbNzM.pgp
Description: OpenPGP digital signature