[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180112003811.GJ1627@brightrain.aerifal.cx>
Date: Thu, 11 Jan 2018 19:38:11 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: alternative form flag with zero octal value
On Thu, Jan 11, 2018 at 08:36:23PM +0100, Jens Gustedt wrote:
> Hello Rich,
>
> On Thu, 11 Jan 2018 13:55:34 -0500 Rich Felker <dalias@...c.org> wrote:
>
> > Yes, there is a good deal of stuff in that file that, in hindsight, I
> > would do somewhat differently. A few of the worst things you noted
> > could be 'fixed' trivially with gotos
>
> No, I don't think this is necessary. I don't mind jumping in the
> middle of an "if (0)" branch, as long as it is indented correcly :)
I'm not sure we're on the same page about what's bad then. I think
if (1) something; else
case bar:
something_else;
is gratuitously less readable than:
something;
goto shared_tail;
case bar:
something_else;
shared_tail:
Ideally we wouldn't need to do either, but sometimes it's hard to
organized the code in a way that's not gratuitously redundant (at the
source level) or gratuitously larger without stuff like this.
> > or compound statatements and
> > probably should be. I don't want a big patch for this file that's hard
> > to review/validate though; the return on time spent is just too small.
> > If anyone does want to push me on making improvements here, small
> > isolated/individual changes that can easily be seen to be correct are
> > the way to go.
>
> Just a patch for white space and indentation would be easy, I think.
I'm not a fan of patches that just recreate the output of an indention
utility.
> - have break at the end of case lines, not at the start
I guess you mean the pop_arg function? It's written the way it is
because that's the form that makes it the easiest to see what's
happening in each case and what's different between them. Putting the
break on a separate line would make it take up a lot more space and
lower the visual SNR. Putting it at the end of the line (without a lot
of alignment space; such space could be an alternative option) would
butt rendundant text up against the part that differs, making it
harder to read too.
One appproach that might satisfy us both is using a macro, something
like:
#define POP_CASE(a,b,c) case a: arg->b = va_arg(*ap, c); break;
obviously with more meaningful names for the args. Then each line of
the switch only contains meaningful information.
> - start a newline before else
> - ident according to musl's coding style
I think a misunderstanding/different expectation you and perhaps
others have is that a "coding style" is a deterministic function from
source token sequences (and possibly some additional metadata like
presence of blank lines) to a canonical source file. Some projects do
things this way, but it's never been something I've liked. To me,
"coding style" means a set of formatting constraints that should
usually be met, unless there's a good reason to break them, but which
don't determine a unique form, plus guidelines for how to favor
readability when there's ambiguity about the best form.
> As long as git diff --color-words shows nothing, this should be fine.
>
> I could such a patch, if you want.
I'd really rather spend time reviewing & merging functional patches
and implementing new things than discussing coding style. As I said
before, if there are individual/isolated changes that can be accepted
or deferred or rejected without requiring a long thread of v2, v3,
..., v10 patches until we agree on which combination of changes is
right, I'm happy to commit the ones I agree with right away, but I'd
still rather be spending time on something that feels more productive.
> Replacing comma operators by compound statements would be a bit more
> work. We could delay that to when somebody touches that file for more
> serious reasons.
Perhaps. Sometimes I'm not sure whether I prefer changing this sort of
thing at the same time as a functional patch or doing it preemptively
so that later functional changes are slimmer and easier to understand.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
