OpaqueValue, a new native type introduced in Issue 2162 (void *
in DII Chapter) for add_arg, was never documented in any of the language
mappings. Language Mapping that claim that the DII interfaces map
according to regular rules need to provide mapping rules for OpaqueValue
and document it. The mapping would simply be OpaqueValue --> (void *) or
equivalent.

The C mapping says in section 1.9:

OMG IDL structures map directly onto C structs. Note that all OMG
IDL types that map to C structs may potentially include padding.

This is not as clear as it should be. In particular, a requirement should
be added to preserve the order of structure members as they appear in the
IDL.

Summary: What if user calls T_allocbuf for a bound sequence with a length that doesn"t match sequence constraint?Does this go undetected?. A related issue is issue # 108

Summary: Sequence buffers are allocated seperately from sequence which contain them, they can be released separately as well. Is this the job of the omnipotent CORBA_free?

Summary: Mapping for IDL typedefs was dropped between CORBA 1.2 and 2.0. It should explicitly stated. Restoring text from 1.2 mapping is probably sufficient

Summary: Loose specification of the #define generated for an exception id: Specification by example is never a good idea. The specification should be more explizit.

Summary: Generate a Seq_releasebuf function for sequence Seq of type T to perform any buffer internal release. Function is called by Seq_freebuf prior to free buffer pointer acc. to release flag

Summary: Generate a Seq_initbuf function to initialize a buffer for sequence Seq of type T. Seq__allocbuf allocates a buffer and calls seq_initbuf to initialize the allocated buffer

Summary: Generate pairs of (T_init, T_alloc) functions for any type T (with descriptions described in issue # 309 concerning T_alloc)

Summary: Define 2 functions, CORBA_exception_init and CORBA_systemException_init to initialize respectively user-defined exceptions and system exceptions to be raised

Summary: Table 22,p 14-20 of C mapping lists argument passing cases. In both cases(3+6) the value is either an out parameter or return value. How to handle CORBA_free as caller or callee

Summary: generate pairs of (E_init, E_alloc) and (E_release, E_free) functions for exception E with behavior similar to the corresponding functions defined for any type T.

Summary: State as undefined the behavior of a sequence as long as its Seq_init function (as specified in issue # 322) has not been called this function initializing the release flag.

Summary: Generate pairs of (T_release, T_free) functions for any type T T_release performs any internal memory release T_free calls T_release and frees the pointer argument

Summary: Define the type of system exceptions to be typedef definitions of a generic system exception type CORBA_SystemException

Summary: Para describes strategy an implementation will use for determining an exception TypeCode. Information not relevant to application developer. Mark as guidance to Implementor.

Summary: Para indicates that all the parameter memory is freed as appropriate when DIR returns. Who frees memory? If DIR frees memory, then change the wording as appropriate.

Summary: Section D.11 presents C mapping for sequence. For performance reasons, Sun prefers to embed the release flag in the sequence.

Summary: In the definition of CORBA_ORB_init environment parameter comes last and it uses env instead of ev. Same inconsitency in CORBA_ORB_list_initial_services/CORBA_ORB_list_initial_references

Summary: vec10 and CORBA_sequence_long: are these distinct types?Would they have distinct typecodes and distinct entries in the Interface Repository?

Summary: Spec contains mutually inconsistent example (p 14-11 and 14-13. P 14-13 suggests that C structure MUST be named CORBA_sequence_long instead and must be enclosed in #ifdef...#endif

Summary: When sequence occurs as anonymous (local) type in a struct,union,etc, how should this be treated?

Summary: Are we supposed to declare and define allocators for new sequence Type? What is acceptable, required, forbidden (in terms of functions)?

Summary: Sec 14.25.2: It"s not clear what happens if CORBA_BOA_set_exception is called more than once for a given object invocation. This should be specified.

Summary: Section D.7 describes the mapping for CORBA_any. Sun would like to replace current C mapping for Any with opaque type, i.e conforming applications may not access members of CORBA_any struct

Summary: In C mapping what is representation of "string" in _value field of an any? "char *" or "char **"? "char **" seems to be more applicable-usage requires an "_alloc" function

Summary: The spec mentions 2 allocation functionsfor sequences of "T". These should better be inside the same (or similar) #ifdef...#endif as the struct typedef

Summary: It refers to a "third case", but there are no cases described, and there are only 2 examples. What are the cases this paragraph refers to?

Summary: There is very probably a small error in the C language specification.
Below is what I wrote to the mailing list concerned with building the ORBit ORB. It
was confirmed by one of the main coders behind ORBit.

> This is something else, but I was more confused because the OMG "C language
> mapping" spec at page 19-39 really seems to contain an error.
> In that example, they also create an application specific servant structure called
> AppServant, and they set the finalizer using
>
> AppServant my_servant = ...
>
> my_servant.epv._base_epv.finalize = my_finalizer_func;
>
> That should really have been (at least, that"s what I think):
>
> my_servant.base.vepv._base_epv.finalize = my_finalizer_func;
>
> I hope you agree with me there, or else I"m probably getting out of touch with C.

Summary: I currently implement a subset of CORBA 2.0. Not CORBA-compliant in terms of C-mapping for arguments to pseudo-objects and real objects. Give clear statement on argument order for real objects

Summary: Example foo::bar on page 14-17 has fixed array out parameter. Mapping shown on this page doesn"t agree with tables 20 and 21.

Summary: Sec 14.11 specifies generation of a buffer allocator for each sequence type of form T* sequence_T_allocbuf (CORBA_unsigned_long_len); very difficult to implement correctly.

Summary: Section 14.28.1, 14.28.2, 14.29: CORBA_string is not defined anywhere in the code sample. These should be typedefed as CORBA_char * or char *

Summary: Section 14.3: Reference is made to CORBA_OBJECT_NIL but there is no defined value for this. A value must be explicitly defined and typed

Summary: The first para of section 14.17 seems to have crept back after a deletion in a n earlier draft- it shouldn"t since it generalizes things (wrongly) which are properly described later

Summary: Spec. should be clear that the pointer passed in out parameters by caller should be uninitialized. This clarification should be in case (3) and (6) of Table 22

Summary: Mapping should be explicit about how release flag interacts with inout, out, and return parameter. There probably is arelated C++ issue

Summary: Sect.14.23: Section indicates that ORBs may restrict the scope of legal operations on pseudo-objects. Minimal subset of operations should be defined so port. applications know what to rely on.

Summary: Section 14.22: Al IDL compilers will generate a C language header. Does that mean that the C Language is required to be supported by all CORBA implementations?

Summary: Information on implementation strategies for pseudo-objects is not relevant to application portability. It should be removed or appropriately annotated as guidance for ORB implementors.

Summary: In case 5 of table 22 in section 14.19, what is the specified behavior if the release flag is FALSE, but the value to be returned is longer than the value specified?

Summary: Section 14.19: Asteriks in table are meant to indicate that item is a C Language pointer. They should not be subscribed.

Summary: Generate T__alloc functions for any type T except interfaces: no function, any: CORBA_any_alloc string: CORBA_string_alloc

Summary: When must this be done? always, whenever the release flag is TRUE, whenever the sequence elements contain secondary storage, whenever it is an out, inout, or return

Summary: Generate a E_free function dual to Ealloc for exception E. /* C API / void E_free (E);

Summary: Generate string literal for exceptions as the stringification of the macro name e.g.for exception E: /*C code generation */ #define ex_E "ex_E"

Summary: Generate a pair of (Seq_allocbuf, Seq_freebuf) functions, for sequence Seq of type T to manage resource of buffer sequences: Seqallocbuf and Seq_freebuf

Summary: The proposal is to state as undefined the behavior of a sequence as lon as its release flag has not been initialized

Summary: Define the _minor field of system exceptions to be of type CORBA_ExceptionMinor

Summary: Reserve the CORBA_exception_id function for user-defined exceptions only.

Summary: Map sequence type names and sequence element type names enclosed within a scope according to the encoding scheme described as follows (/archives/issues/issue314)

Summary: Deprecate use of CORBA_free and generate T_free functions for any type T instead. Specification of T_free is current spec for CORBA_free suitable for type T

Summary: Add release flag to generated C structure and map IDL sequence type from following definition (/archives/issues/issue311)

Summary: Define a library function CORBA_Environment_init to initialize the non-opaque fields of CORBA_Environment (see file)

Summary: Why is it not CORBA_sequence_CORBA_long? What is the precise rule by which these names are constructed?