[U-Boot] GCC 7.x vs. C++ comments

Wed May 9 16:14:56 UTC 2018

On Wed, May 09, 2018 at 05:40:52PM +0200, Wolfgang Denk wrote:
> Dear Tom,
> 
> In message <20180509134905.GK12235 at bill-the-cat.ec.rr.com> you wrote:
> > 
> > > Marek already said what was on my mind, and got ignored.
> > > Would it have changed anything if I had posted another complaint?
> >
> > Ignored, no.  Counts as a veto?  No.  And if you had chimed in too, I
> > don't know if that would have gotten anyone else to also chime in.
> 
> This does not really convince me.
> 
> IMO it makes no sense to blow up mailing list traffic with extensive
> voting for such things. Marek said everything that needed to be
> said, and repeating it would IMO not add any weight to it.  If you
> really want a poll including more people, then explicitly start one
> - but please not on the mailing list, at least not fuch such
> details.

I honestly couldn't think of a better way to see if anyone cared besides
an RFC to the mailing list.

> > It's not futile, but here's as best I can tell, the arguments:
> > Against Linux Kernel style SPDX tags:
> 
> I think this argument is wrong from the start.  This is not about
> "Linux Kernel style SPDX tags".  There is two different topics,
> which are actually independent, and should be treated as such:
> 
> - Linux Kernel style SPDX tags, or rather more modern SPDX tags
>   including the needed operators to deal with exceptions, multiple
>   licenses, etc.  When I invented the SPDX tags I did not foresee
>   this need (my fault), but I'm still proud that U-Boot introduced
>   this mechanism at all.
> 
>   Yes, it is necessary to adapt the new developments in this area.

And for the record, it's a good thing you did.  Since we were the best
example of a project going all-in on the tags for a long while I know
the people that did the kernel scheme looked at what we had.

> - Comment style.  This is just a matter of coding style and
>   preferences.  Whether you use C comments (single line or
>   multi-line) or C++ comments does not make any difference
>   technically.

I disagree on these being separate.  I copy/pasted the relevant part of
the kernel documentation as an update to our doc but where it goes
(first line) and how it goes (comments like ....) are as much a part of
the style as the syntax.  I'd argue that where the license copies go and
some directory structure there-of is also part of it but I think our
locations are more set in stone, but we can live with it.

>   U-Boot has been discouraging the use of C++ comments for 18 years,
>   and I still see no good reason to change this.  [And yes, we also
>   have the rule not to meddle with code copied from other projects.]

I don't want to have it buried here but maybe it's time to talk about
fully adopting C99 (or, GNU C99).  Did you happen to read
https://lkml.org/lkml/2017/11/25/133 that Yamada-san passed along?
Having read that after converting the tags that my first regex missed,
maybe we were wrong 18 years ago.

> > - Don't like // style comments
> > - Visually inconsistent / jarring
> 
> - Against existing coding style.
> 
> 
> > For Linux Kernel style SPDX tags:
> > - Has higher visibility.
> 
> ??? I can't parse this.  In which way has
> 
> // SPDX-License-Identifier: GPL-2.0+
> 
> "higher visibility" than
> 
> /* SPDX-License-Identifier: GPL-2.0+ */
> 
> or even

I was pointing out first line vs somewhere within the top comment block
as I don't consider comment format vs location different items.

> /*
>  * SPDX-License-Identifier: GPL-2.0+
>  */
> 
> ?
> 
> [IMO, the last form is the most visible one.]
> 
> And since when do we care about a single line of white space or two
> when it comes to consistency or readability?
> 
> > - Has tooling to enforce correctly formatted tags.
> 
> 
> > - Shorter (enforced as a single line comment means we don't have people
> >   spacing around it).
> 
> Come on, this argument is really lame.

That the SPDX tag meant the same as the whole license text was part of
the reason to convert.

> > - Consistent expectations for our overlapping developer community.
> 
> Please explain?  Who associates SPDX tags with C++ comments?  This

This is again part of the difference in counting comment format as part
of it, or not.

> is silly.  We don't use these in Makefiles, or in shell scripts, or
> in ...

We sometimes do for Makefiles, almost always do in shell scripts.

> And when talking about consistency - what about this in the current
> Linux Kernel tree:
> 
> arch/x86/kernel/apic/apic_common.c: * SPDX-License-Identifier: GPL-2.0
> arch/s390/tools/gen_opcode_table.c:/* SPDX-License-Identifier: GPL-2.0 */
> arch/arm64/crypto/sha3-ce-glue.c:/* SPDX-License-Identifier: GPL-2.0 */
> arch/arm64/crypto/sha512-ce-glue.c:/* SPDX-License-Identifier: GPL-2.0 */
> arch/riscv/kernel/ftrace.c:/* SPDX-License-Identifier: GPL-2.0 */
> arch/riscv/kernel/module-sections.c:/* SPDX-License-Identifier: GPL-2.0
> drivers/tty/hvc/hvc_riscv_sbi.c:/* SPDX-License-Identifier: GPL-2.0 */
> drivers/memory/brcmstb_dpfe.c: * SPDX-License-Identifier: GPL-2.0
> drivers/soc/amlogic/meson-mx-socinfo.c: * SPDX-License-Identifier: GPL-2.0+
> drivers/soc/amlogic/meson-gx-pwrc-vpu.c: * SPDX-License-Identifier: GPL-2.0+
> drivers/soc/amlogic/meson-gx-socinfo.c: * SPDX-License-Identifier: GPL-2.0+
> drivers/i2c/busses/i2c-sprd.c: * SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> drivers/pinctrl/meson/pinctrl-meson-axg-pmx.c: * SPDX-License-Identifier: (GPL-2.0+ or MIT)
> drivers/pinctrl/meson/pinctrl-meson-axg.c: * SPDX-License-Identifier: (GPL-2.0+ or MIT)
> drivers/virt/vboxguest/vboxguest_core.c:/* SPDX-License-Identifier: (GPL-2.0 OR CDDL-1.0) */
> drivers/virt/vboxguest/vboxguest_linux.c:/* SPDX-License-Identifier: GPL-2.0 */
> drivers/virt/vboxguest/vboxguest_utils.c:/* SPDX-License-Identifier: (GPL-2.0 OR CDDL-1.0) */
> drivers/watchdog/rtd119x_wdt.c: * SPDX-License-Identifier: GPL-2.0+
> drivers/rtc/rtc-rtd119x.c: * SPDX-License-Identifier: GPL-2.0+
> drivers/rtc/rtc-sc27xx.c: * SPDX-License-Identifier: GPL-2.0
> ...
> 
> 
> Yes, 47 files is only a small fraction compared against the 5261
> C files with C++ commented tags. But consistency of apparently not a
> real issue when it comes to comment style in Linux.

Inconsistent rollout?  Tags went in good bit before the document that
said how/where they should be was finally merged.  I'm sure it's on the
kernel janitors list for someone to fixup, or there's patches slowly
in-flight to do so.

> > Things that could be taken, without changing overall formatting:
> > - Logic operators for exceptions/dual-license/etc
> 
> Right, this is completely independent and out of question here.

Agreed.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20180509/8a8c4ef7/attachment.sig>