Re: [gpsd-dev] C99 Aftermath

[Fred Wright]

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.

> > > As noted above, I'd like the C99 enforced for Linux.  That will
> > > keep a lot of junk from creeping back in.  Can you do the #ifdef
> > > wrap and resubmit?
> >
> > Even if one were to take that approach, there's a nontrivial amount of
> > work in determining the *right* thing to do in the Linux case,
>
> 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.

> > In theory, one could simply say "CC=c99 scons ..." in many
> > cases,
>
> Sadly, only one, Linux.  So just hard code it.

I mean for testing, and that works on any platform with a "c99" command.

> 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.  I often see them delivered
out of order here, since my ISP has multiple load-balanced mailservers.
Another mark against the patches-by-email approach. :-)

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.
I didn't want to mix up intracommit edits with the big revert (though I
did have to fix one conflict).  That one patch alone is enough to get the
code back to a fully working state on all targets.  The remaining 5
patches then reintroduce the changes to be kept in non-verbatim form.
They almost correspond 1:1 with the commits labeled 'P' and 'R' in the
first commit message, except that I split the gps_usleep() change into two
commits, one for the main code and one for contrib/.  If the patches are
applied in order, then every intermediate state of the code is fully
working.

Indeed git-bisect is somewhat broken for this stuff, but that's the result
of the *already committed* changes that broke things.  The only way to fix
that completely is to rewrite history, which has its own problems.  The
best thing to do under the circumstances is to get the code back to a
fully working state as quickly as possible, which is what the first patch
does.  It's true that with this sequence of patches, some C99 compliance
goes away and comes back again, but nothing is enforcing it anywhere in
the series, anyway.  So unless you're planning to git-bisect with "CC=c99"
or some such, you won't notice. :-)

BTW, that's also why any reintroduction of something to actually force C99
mode should only happen *after* this set of patches.

Fred Wright