-*- text -*-

Stuff that should still be done on the ASN.1 encoder conversion:

* Add support for opaque objects (pre-encoded fields, or ANY), and fix
  up those remaining encoders (e.g., asn1_encode_sam_challenge_2) that
  need them.

* Convert PKINIT encoders, after we have test cases.

* Make offsetof uses conforming.  Currently we may use foo.bar or
  foo[0] as fields.

* Script to generate the tables.  Then each type or field entry can
  generate multiple bits of code, instead of forcing us to bury the
  type consistency checking into the structure initializer
  expression.  For example, we might generate these bits of code from
  one field descriptor:

  * Field table entry.

  * Type-checking code: Create a pointer of the expected type and a
    pointer of the actual type (address of field of automatic struct),
    and verify consistency with comparison, assignment, or conditional
    expr.  Plenty of comments to indicate what's being compared and
    what a compiler complain means.

  * Range-checking code for bitfields: Create an automatic field info
    struct, fill in the computed offset or whatever, read it back,
    make sure it matches.  Also with comments.

  * Possibly header declarations describing the types that could be
    imported, with correct handles *and* C types.

  * Static declarations for non-exported types to keep symbol table
    sizes down.

  Then similar bits of code (e.g., all the field table entries) can be
  pulled together into the appropriate places.

* Some kind of "module" system for exporting and importing encoders,
  better than relying on the "type_*" variable names.  Probably use
  meaningful strings that indicate both the ASN.1 type and the
  associated C type.  Find a way to fit "imported type" into this
  scheme so that we can cleanly move the PKINIT types into the PKINIT
  plugin, the LDAP types into the LDAP plugin, etc., and still let
  them use the encoders in the code.  Only a subset of types would be
  exported probably.

* More compact encoding: For tags and optional-field bit positions,
  encode N+1, and use 0 for "none", then make the field unsigned.
  Currently the fields are signed, non-negative values hold useful
  data, -1 means "none", and MIN..-2 are unused.  Changing this will
  either let us reduce the field size one bit, or extend the maximum
  tag/bitpos value from 2**(N-1)-1 to 2**N-2.

* More compact encoding: Use a union with designated initializers, or
  some ugly casting, to make the structures smaller by not having all
  fields present when we never use all of them at once.  The union
  approach is certainly more appealing, aside from the little detail
  that it won't work on Windows unless we do all the initialization at
  run time.

* Pie in the sky: A verbose mode that can tell you "missing field
  KDC-REP.cname.name-string[1].data" or some such.  This would require
  tracking the stack of pending encodes and adding strings with type
  and field names.

* For ALL_POINTERS_ARE_THE_SAME mode (which is not strictly conforming
  with the C standard, and thus not default currently, but makes
  things a little smaller and faster), eliminate the loadptr structure
  entry.

* Maybe: Reorganize the data of a "module" so everything needing
  relocation is put in some tables, referenced by index from other
  structures without relocations.  E.g., for krb5_data, here's the
  offset for the data pointer, here's the offset for the length value,
  here's the index into the pointer reader function table, here's the
  index into the length reader function table, here's an index into
  the string-type encoder table.

  Using an index into a set of pointer types, with a single function
  taking an integer parameter used to switch between various
  ptr-to-ptr-to-type code paths, will be a lot smaller -- with a good
  compiler the function will probably collapse to a simple
  fetch-a-pointer function ignoring the integer argument, while at the
  C level it's strictly conforming by using the correct types for
  access.

* Table-driven decoders?