[fuse-emulator-devel] Coding style / supported C variants

[Stuart B. <sd...@zu...>]

Hi all,

Our code isn't quite C90 or POSIX, and I'd like some opinions on this.

In particular:

 * We have trailing commas in our enums, which is not permitted by C90.
   This was a mistake in the specification, as far as I am aware.
   No sensible compiler rejects trailing commas in enumerations to my
   knowledge, but there are silly compilers that do.  I gather the silly
   compilers that do this are mostly proprietary compilers for embedded
   systems, that we're unlikely to ever care about.

 * We avoid trailing commas in structs, but these are permitted by C90.
   Using makes diffs clearer, and eases merges, as we avoid changes that
   simply add a comma to the end of a line.  If anyone here programmed in
   Pascal, perhaps you were aware that ";" was a statement separator and
   not a statement terminator.  One generally doesn't omit the final ";"
   before an "end" though, as there's next to no benefit in doing so.
   This tends to bug me whenever periph_t gets updated, and I am in the
   process of adding an extra member to this.

 * We use "_t" as a suffix for type definitions.  This uses namespace
   that is reserved for POSIX.  This should be generally discouraged as
   one can never be sure whether POSIX will be extended to make use of
   any identifier you have chosen matching this pattern.  Sure, you can
   argue that libspectrum_malloc_fn_t is unlikely to ever be defined by
   POSIX, but it's simplest just to have a clear, consistent rule.

 * We have a few C++ "//"-style comments despite coding_style.txt telling
   us not to.

I don't want to go down the route of 500-page corporate coding standards
documents that achieve nothing practical[0], but I'm thinking of making
some changes across the source tree adding one or two words to the style
guide if there are no objections.

Sound okay?
-- 
Cheers,
Stuart

[0] Goodness me, I've seen such things, too, including a ban on lvalues
    to the left of the "==" operator.  It was not even clear if this
    applied to the inequality operator ("!=") or even the relational
    operators, but people were afraid it might do, so avoided this too.
    Let's not go down that route. :-)