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

Wolfgang Denk wd at denx.de
Wed May 9 15:40:52 UTC 2018


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.

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

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

  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.]

> - 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

/*
 * 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.

> - Consistent expectations for our overlapping developer community.

Please explain?  Who associates SPDX tags with C++ comments?  This
is silly.  We don't use these in Makefiles, or in shell scripts, or
in ...

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.


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

> If people speak up against the change now that we've done it, we could
> revert and then add in the "LICENSE-A OR LICENSE-B" change.  Thanks!

I have always been against the use of C++ comments in U-Boot (and in
general in non C++ code), and I still am against it.

Not that this matters much.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The rule on staying alive as a program manager is to give 'em a  num-
ber or give 'em a date, but never give 'em both at once.


More information about the U-Boot mailing list