-*- mode: Text -*- BUGS, CAVEATS, AND WORK IN PROGRESS Flick 2.1 November 1999 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 . ----- FRONT ENDS ----- The CORBA front end signals an error if a `context' expression is used. 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 nums); Right typedef sequence 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 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: 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. CORBA-style typed allocators are not yet implemented in the CORBA C language presentation. The CORBA C language 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 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. 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 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 ----- 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.) Flick's CORBA runtime for C language stubs (in `runtime/libraries/link/iiop') does not yet support `any' values. If you need `any's, consider using Flick's CORBA C++ components instead. Flick-generated C++ stubs use the `any' support provided by TAO, the real-time ORB from Washington University in St. Louis. See for more about TAO. A few of Flick's CORBA C language 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. In Flick's CORBA C language runtime, some of the operations defined for CORBA Objects are unimplemented. (See Section 7.2 of the CORBA 2.0 specification.) In general, Flick's CORBA C language 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'). If you need a full-fledged CORBA ORB, consider using Flick's CORBA C++ components in conjunction with TAO, the real-time ORB from Washington University in St. Louis. Flick generates optimized C++ stubs that work with TAO. ----- 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.