=============
What's to do?
=============

for future releases (in no special order):
------------------------------------------

* do we need a GCC bitfields engine? (dcc, ...?)

* test bitfields in bench.pl

* add tags to bench.pl

* compile with normal perl and -Wall will show some interesting
  warnings (uninit, unused, ...)
    => try gcc-4.1

* add UnsignedBitfields probe to ccconfig (only for run mode, not
  sure if compile mode is possible at all)

* introduce UnsignedChars and UnsignedBitfields for native method?

* see if the Microsoft algorithm can be improved?

* extend sizeof() to support size of bitfields with .bits notation???

* add checks for bitfield behaviour to ccconfig

* parser tests: negative array index => make parse error?

* redirect stderr of test 901 (use same tricks as in D::PPP)

* eliminate croak_gti()?

* we need much better parser tests...

* can we simplify _expressions in the parser with %prec ?

* instrument both parser.y and pragma.y with %printers ?

* improve errors with locations (see bison.pdf) ?

* parse expressions into a tree

   => write an optimizer for the tree that simplifies
      constant arithmetics

   => really short-circuit on boolean expressions

* more 'basic type objects' tests

* add 'indent' option to initializer()

* add 'unnamed' => 0|1 to sourcify options

* instrument fatal() to include file/line

* what about CAN_UNALIGNED_ACCESS ?

* use inline functions instead of macros where possible (for gcov)

* more test coverage for the parser

* use D::T::C for arg() method?

* port docs to Text::GenDoc (release T::G first ;-)

* handle Cray behaviour

* support conversion to new 5.10 (un)pack templates

* finish work on flexible array members (done?)

  - make member() work better
  - make complex.t introduce fams

* is T_ALREADY_DUMPED thread-safe, or should we
  rather use a hash to memorize the dumped types.

* support for unsigned and 64-bit integer arithmetics

    use ucpp's (reentrant) arith.c?

* make cast operators work

* on parse error, print parser stack?

* patch ucpp to only warn about missing newline
  termination

* have an eval method that allows to evaluate a
  constant C expression (including preprocessor
  expansion), so

    $c->parse( <<ENDC )
    #define FOO 1
    #define BAR 2
    #define VALUE (2*FOO+BAR)
    ENDC

    print $c->eval("VALUE+2");

  would then print 6.

* update / cleanup test suite using Test::More

* make sizeof/offsetof files plain text files and
  parse them on the fly. get rid of 'do'

* make offsetof test similar to sizeof test (sizeof.pl)

* add tests for ccconfig (using a "virtual" compiler?)

* add more floating point tests (NaN and stuff?)

* support #pragma pack( (push|pop) [, id] [, pack] ) ?

* what about

    #define foobar 2
    #pragma pack( push, foobar )

* support gcc's __attribute__, at least for struct packing
  (actually, this is worse than it seems, because it behaves
  completely different than #pragma pack...)

* support constant address arithmetics

  - this is mainly needed for the offsetof C macro and
    similar stuff, eg

      enum { OFFSET = offsetof( struct foo, bar ) };

    doesn't work yet. But I guess such construct is rarely
    used.

* cleanup unsafe values handling

* support arbitrary byte order? ( ByteOrder => '13248756' )

* add platform independent IEEE floating point support
  (SoftFloat or sth. similar?)

* have a definition() method?
  Like typedef/compound/enum, but for all of 'em?

* try to give a hint to where a parse error occured
  COPY_LINE ?

* maybe add DollarsInIdentifiers, AtSignsInIdentifiers?

* add some warnings during parsing
  - empty arrays in structs a[] (not at end of struct)

* add tests for all preprocessor warnings/errors?

* add a more complete preprocessor testsuite?

* character arrays => strings?

* perhaps bless (tie) long double SV's and store binary data (?)

* sourcify only specific types (pass in a list of types) (?)

* Subject: AW: C::B::C und h2ph/c2ph
  From: "Dintelmann, Peter" <Peter.Dintelmann@Dresdner-Bank.com>
  Date: Tue, 14 Dec 2004 14:20:39 +0100
  Message-ID: <E9A2605289D8D7468B1A21EC24E59D2115AA12@naimucx5.muc.allianz>

  Das Aufloesen der typedefs wuerde fuer mich persoenlich
  die Lesbarkeit erleichtern und den Quelltext vereinfachen.
  Im Beispiel "struct futmpx" hat man unter anderem mehrere
  Faelle der Art

      typedef int int32_t;

      typedef int32_t pid32_t;

      struct futmpx
      {
              char ut_user[32];
              char ut_id[4];
              char ut_line[32];
              pid32_t ut_pid;
              ... ... ...
      };

  und ich wuerde viel lieber gleich

      struct futmpx
      {
              char ut_user[32];
              char ut_id[4];
              char ut_line[32];
              int ut_pid;
              ... ... ...
      };

  haben koennen (und auf die zwei typedefs verzichten).

* add an object representing a single type?

  - for example:

      $p = new Convert::Binary::C;
      $p->parse_file( 'some_code.h' );
      $type = $p->get_type( 'type' );
      $data = $type->unpack( $raw );

    (no, I didn't think about how to name any of the new stuff ;)

  - should use less memory
  - should allow for serializing
  - should allow for use with PerlIO layers (?)
  - I have to think about that!!!
  - Any suggestions are strongly appreciated!