Issues for C Language Mapping RTF mailing list

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 111: Inout sequence/any behavior with oversized return values
Issue 165: Wrong placement of asterics in table
Issue 166: C Language header question
Issue 167: Pseudo-Object underspecification
Issue 169: Inappropriate information (Sect. 14.23. last paragraph
Issue 171: Parameter memory freeing problem (Section 14.24.1.para 6)
Issue 172: implementation hints not specification (Section 14.24.2 last para)
Issue 174: What happens when set_exception called more than once?
Issue 175: confusing presentation (Section 14.25.4)
Issue 176: inconsistent parameter name and order
Issue 177: C mapping for sequence (Section 14.11 CORBA 2.0)
Issue 181: Representation of "string" values in an "any"
Issue 243: C mapping for Any
Issue 291: Spec contains mutually inconsistent examples
Issue 292: vec10 and CORBA_sequence_long
Issue 293: Allocation Functions for sequences of "T"
Issue 294: Declare and define Allocators for new sequence type
Issue 295: sequence as anonymous type in struct
Issue 296: CORBA_sequence_long
Issue 297: When MUST _buffer of sequence be allocated with _allocbuf
Issue 309: memory allocation functions
Issue 310: memory release functions
Issue 311: mapping for sequences
Issue 312: Sequence behavior
Issue 313: Sequence buffer management
Issue 314: Scoped sequence naming
Issue 315: Exception stringification
Issue 316: Exception release function
Issue 317: CORBA_Environment initialization
Issue 318: Exception identification
Issue 319: Minor field of system exceptions
Issue 320: System Exception Type
Issue 321: Exception initialization
Issue 322: Allocation and initialization
Issue 323: De-allocation and release
Issue 324: Sequence initialization
Issue 325: Sequence buffer initialization
Issue 326: Sequence buffer release
Issue 327: Exception initialization and release
Issue 328: Argument passing, cases 3 and 6
Issue 329: Exception id name
Issue 331: Mapping for Aliases
Issue 333: Seq buffer deallocation
Issue 334: Bound seq buffer allocation
Issue 335: release flag & returned data
Issue 336: Seq buffer allocation
Issue 462: Example inconsistent with table 20 and table 21
Issue 485: Initial state of out parameter pointers
Issue 486: Delete 14.17 para 1
Issue 606: No defined value for CORBA_OBJECT_NIL
Issue 620: CORBA_string is not defined
Issue 636: Inconsistency in CORBA 2.0 C mapping
Issue 2307: Error in C language specification
Issue 4341: Order of structure members
Issue 5778: OpaqueValue needs to be documented in the C Language mapping

Issue 111: Inout sequence/any behavior with oversized return values (c_mapping-rtf)

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: 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: 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: 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: 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: Para describes strategy an implementation will use for determining an exception TypeCode. Information not relevant to application developer. Mark as guidance to Implementor.

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: 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: 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: Section D.11 presents C mapping for sequence. For performance reasons, Sun prefers to embed the release flag in the sequence.

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: 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: 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: vec10 and CORBA_sequence_long: are these distinct types?Would they have distinct typecodes and distinct entries in the Interface Repository?

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: Are we supposed to declare and define allocators for new sequence Type? What is acceptable, required, forbidden (in terms of functions)?

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

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

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 T__alloc functions for any type T except interfaces: no function,      any: CORBA_any_alloc                                              string: CORBA_string_alloc

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: The proposal is to state as undefined the behavior of a sequence as lon as its release flag has not been initialized

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

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: 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 E__free function dual to E__alloc for exception E.        /* C API */                                                         void E__free  (E*);

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

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

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

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

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

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

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: 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 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 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 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: 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: 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: 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: 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: 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: Mapping should be explicit about how release flag interacts with inout, out, and return parameter. There probably is arelated C++ issue

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: 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: 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: 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: 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

 moved to C Mapping RTF

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: 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: 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.
 

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.

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.