qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v12 27/36] qapi: Forbid case-insensitive clashes


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v12 27/36] qapi: Forbid case-insensitive clashes
Date: Thu, 19 Nov 2015 17:50:44 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Let's think through this on a higher level.

I figure the motivation for this patch is twofold:

1. C identifier clash detection

   We generate C identifiers derived from QAPI names.  These can clash
   with (1) each other, (2) C keywords and selected other well-known
   identifiers, and (3) the user's identifiers.

   We avoid (2), and we make an effort to catch (1). because that's
   friendlier than letting the compiler catch it.  (3) is the user's
   problem, and there's nothing we can do about it.

   Clashes are due to (a) folding [-._] to _, (b) case folding, and (c)
   name space intrusion, e.g. a type Foo_lookup clashes with an enum
   type Foo's lookup table.

   We make an effort to prevent (c) by reserving names.  We make an
   effort to catch (a) and (b).

2. Dislike for interfaces that differ only in case

   I agree defining such interfaces is a bad idea.  However, forbidding
   bad ideas is problematic, because where do you stop?  There's an
   infinite supply.

   Forbidding makes sense when the bad idea is a recurring problem, or
   when it causes technical difficulties.

   There's been one instance of this bad idea so far: command 'stop' and
   event 'STOP'.  We can't fix it, because it's ABI.  The patches
   proposed so far can't even prevent its recurrence; events and
   non-event entities that differ only in case remain valid.  Any other
   combination becomes invalid.

   A rule "cannot differ only in case" is okay, but with "except for
   events and non-events" tacked on, it becomes ugly.

   The case for rejecting names that differ only in case appears weak.

Our naming conventions actually make clashes due to folding relatively
unlikely.  They are:

* All names consist of letters, digits, '-' and '_', starting with a
  letter.

* Event names are ALL_CAPS, i.e. they use neither lower case nor '-'.

  Without lower case, '-' and '.', clash due to folding is impossible.

* Command names, member names and built-in type names are dashed-lower,
  i.e. they use neither upper case nor '_'.

  Without upper case, '_', and '.', clash due to folding is impossible.

* Type names are CamelCase.  They do not use '_' or '-'.

  Can theoretically clash in amusing ways: ONegus, OneGus.
  Ain'tCamelCaseFun!

  We can get rid of the clashes by not case folding type names.  See
  "[PATCH RFC 3/5] qapi: Use common name mangling for enumeration
  constants".  The patch additionally drops folding of enumeration
  member names, which isn't necessary.  Controversial.

* Additionally, any name may be prefixed by __RFQDN_.  RFQDN consists of
  letters, digits '-' and '.'.

  Because unprefixed names start with a letter, and the prefix starts
  with '__', prefixed names cannot clash with unprefixed names.

  If we additionally stipulated that event prefixes are upper case, and
  all others lower case, prefixes couldn't contribute to clashes at all.

Strict adherence to our naming conventions would eliminate clashes due
to folding except for type names.  A single extra dictionary mapping
c_name(typ.name).lower() to typ would suffice.

What happens to the rest of your queue if we shelve this patch for now?



reply via email to

[Prev in Thread] Current Thread [Next in Thread]