-*- mode: Text -*-

		      BUGS, CAVEATS, AND WORK IN PROGRESS

				   Flick 1.1

				   May 1998



This list of bugs, caveats, and unimplemented features is organized more or
less according to Flick's compilation phases.  It is *not* organized by
priority.

Please send Flick bugs reports and fixes to <flick-bugs@cs.utah.edu>.


			    ----- FRONT ENDS -----

The CORBA front end signals an error if the `any' type is used.  This is
because the current presentation generators don't support `any' types.

The CORBA front end signals an error if a `context' expression is used.  Again,
this is because the current presentation generators don't support CORBA-style
contexts.

The CORBA front end does not accept the extensions to the CORBA IDL that are
parsed by SunSoft's publicly available CORBA front end.  In particular, Flick
does not allow a sequence or array type to be declared ``inline'' as a
parameter type.  For example:

   Wrong	short sum(in sequence<short> nums);

   Right	typedef sequence<short> short_seq;
		short sum(in short_seq nums);

The CORBA front end does not recognize the `#pragma' directives described in
Section 6.6.4 of the CORBA 2.0 specification.  These pragmas allow programmers
to specify the format of ReposityIDs.  The CORBA front end has nowhere to
record this information in the generated AOI file.

The ONC RPC front end (the `rpcgen' IDL parser) allows only one argument to be
passed to each operation.  This conforms to the older specification of the Sun
RPC language.  (RFC 1831, dated August 1995, allows for multiple arguments and
in-argument-list type specifications.)  Further, Flick's Sun RPC front end does
not recognize the keywords `hyper' and `quadruple' described in RFC 1832.  A
future release of Flick will support RFCs 1831 and 1832.

The ONC RPC front end does not handle the `%' directive that `rpcgen'
interprets to mean ``pass this line to the output file.''  Flick's ONC RPC
front end generates AOI, and there is no place in AOI to include C code.

The MIG front end/presentation generator was recently repaired, but does not
yet support all of the MIGisms you may love (or hate).  Things not yet working
include:

  statements:	waittime/nowaittime	msgoption

  param types:	serversecid/usersecid

  IPC flags:	dealloc[]	countinout	samecount
		physicalcopy	overwrite	retcode

  misc:		doing asynchronous RPC using two distinct simpleroutines
		specifying a buffer for `out' parameters
		passing arrays of polymorphic types


		      ----- PRESENTATION GENERATORS -----

There are still some unwarranted dependencies between certain front ends and
presentation generators.  Although the CORBA and ONC RPC front ends both
produce AOI files, the CORBA and ONC RPC presentation generators are still
``tuned'' to the AOI constructs generated by the respective front ends.  This
means that at the moment, the CORBA and Fluke presentation generators can input
only AOI files generated by the CORBA front end, and similarly, that the ONC
RPC presentation generator can input only AOI files generated by the ONC RPC
front end.

As mentioned above, the CORBA presentation generator does not support the CORBA
`any' type, nor does it support CORBA contexts.

The CORBA presentation does not yet support `CORBA_sequence_{get,set}_release'.
Sequences always ``own'' their buffers.

CORBA-style typed allocators are not yet implemented.  The CORBA presentation
generator creates presentations in which heap memory is allocated with the
type-independent functions `CORBA_flick_alloc' and `CORBA_flick_free'.
(`CORBA_alloc' and `CORBA_free' are aliases for these functions.)  To release
an object reference, one must explicitly call `CORBA_object_release'.

The CORBA presentation generator cannot always set the correct allocation
semantics for named (typedef'ed) string types.  The PG will print a warning
whenever this occurs.  In practice, when this problem occurs, the generated
client stub will fail to deallocate the storage used by the `in' version of an
`inout' string.  (Workaround: Keep a pointer to the string and free it after
the client stub returns.  Or, don't typedef your string types.)

Similarly, CORBA client stubs fail to deallocate the `in' versions of buffers
within `inout' sequences.  (Use the keep-a-pointer workaround described above.)

Flick does not treat omitted union discriminator values in a CORBA IDL file as
(implicit) void union branches (Section 3.8.2 of the CORBA 2.0 specification).
Rather, the code generated by the back end will signal errors for ``missing''
discriminator values.  (The upshot: at the moment, one can't create a CORBA IDL
union with a void branch.)

The ONC RPC presentation generator does not produce `rpcgen'-like marshal and
unmarshal stubs.

The Fluke (MOM) presentation generator may produce bad code for recursive data
types.  This is because all references are ``unqualified''; for example, we
always refer to `struct foo' as `foo', never `struct foo'.  We do this for
esoteric reasons.  Eventually, we can fix self-referential data types by
changing the PG library to separate the name definition from the structure
definition (e.g., as in `typedef struct foo foo; struct foo { ... };').

Not all of the name format command line options (the `--..._fmt' options) are
wired up.  One should not get too attached to any of these options in any case,
because eventually, they will all go away and be replaced by a more general
presentation modification facility.


			     ----- BACK ENDS -----

If a server work function raises an exception, Flick-generated code may fail to
free the memory allocated for `inout' parameters.  There may be other memory
leaks in the generated code as well.

If a catastrophic runtime error occurs (e.g., out of memory), Flick-generated
code will fail to free memory that it has allocated.  Error handling is not yet
100%.  The results of memory allocation functions are not checked; the result
codes returned by runtime IPC functions are not checked; etc.  Improved error
handling is a top priority.

The back end of the compiler uses ``speculative code generation'' in order to
optimize memory management for marshaling/unmarshaling arrays and discriminated
unions.  In particular, the compiler generates the marshal/unmarshal code once,
examines the resultant memory allocation state, and then regenerates the code
using the information gained from the first attempt.  Clearly, this technique
means that the number of code generation passes will increase exponentially as
the depth of the marshaled/unmarshaled structures increases.  We are aware of
the problem and expect to implement a better code generation technique in the
next major release of Flick.

The Mach3MIG transport mechanism does not currently support 64 bit integers.
Code will be generated, but the glue code for this has not been written.

The Sun (ONC/TCP) back end cannot process `.prc' files that were generated by
the MIG front end/presentation generator.  This is because the Sun back end
tries to invent ONC RPC program, version, and operation codes for `.prc' files
that are derived from non-ONC RPC IDLs.  Unfortunately, the `.prc' files
produced by the MIG presentation generator do not have the data required by the
Sun back end for this process.

The Sun (ONC/TCP) back end does not zero the pad bytes that follow a string or
an opaque array, although this is required by the XDR specification.  The pad
bytes *are* present (so the string or array ends on a four-byte boundary) ---
they just aren't set to zero.  In practice, however, this is not a problem
because neither Flick- nor `rpcgen'-generated code examines these pad bytes.


			  ----- RUNTIME SUPPORT -----

Remember that Flick's runtime libraries are not built or installed as part of
the normal `make' process.  You must build and install any runtimes you need by
navigating into the runtime directories (`runtime/libraries/link/*') and
invoking `make' there (`make' or `make install').

We have recently started to reorganize our runtime support into separate
presentation, encoding, and link components.  The goal is to make each layer
independent from the others, thereby supporting mix-and-match interoperability.
This task is not yet complete, however, so certain combinations may not work.
(All of the ``native'' combos --- CORBA on IIOP, ONC RPC on Sun/TCP, MIG on
Mach 3, and Fluke on Fluke --- should work.)

A few CORBA runtime functions differ from their CORBA 2.0-specified signatures.
Most notably, `CORBA_BOA_create' takes different arguments because Flick
currently has neither an Interface Repository nor an Implementation Repository.
See the Flick user's manual for details.

Some of the operations defined for CORBA Objects are unimplemented.  (See
Section 7.2 of the CORBA 2.0 specification.)  Most notably, `is_a' is not
available.

In general, the CORBA runtime support is *extremely* sparse.  Flick does not
provide a full-fledged ORB.  Read the Flick user's manual for more information
(`doc/usersguide/user.ps').  In the future we expect to modify Flick's IIOP
back end (or implement new back ends) to produce stubs for one or more
third-party ORBs.


		      ----- TEST / EXAMPLE PROGRAMS -----

Except for `test/examples/phone', the example applications in `test/examples'
are not up to date and may not compile at all.  The tests in `test/programs/*'
for ``matched'' front end/presentation generator/back end combinations should
compile, however.


			      ----- GENERAL -----

For reasons described above, the ONC RPC components of Flick are not a drop-in
replacement for `rpcgen'.  In particular:

  + Flick does not generate XDR marshal/unmarshal routines.
  + Flick does not handle `%' directives in the input `.x' file.
  + One can't use `librpc' runtime routines such as `clnt_create', `clnt_call',
    and so on in conjunction with Flick-generated RPC stubs.

In short, the ONC RPC parts of Flick are designed to produce RPC interfaces
that look like those produced by `rpcgen'.  However, the generated functions
work differently on the inside, and Flick doesn't support the features of
`rpcgen' that aren't directly related to the ONC RPC IDL.  In the future, we
may provide more in the way of `rpcgen'-like runtime support.

One final problem is that, by design, the compiler does not free memory.  This
is not a big problem in the front end or in the presentation generation phase.
However, in the back end, ``speculative generation'' of code for purposes of
optimization can cause memory usage to get out of hand.  In the future this
probably will be handled with one of the many C++ garbage collection schemes
--- volunteers welcome.


## End of file.

