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 53: C keywords
Issue 104: Problems with underscores
Issue 105: All interfaces must be defined at global scope?
Issue 106: Unions represented with either union or struct
Issue 107: Sequence release flag implementation
Issue 108: Confusing sequence example
Issue 109: Malloc problems with sequence types
Issue 110: Suggested optimization for string duplication
Issue 111: Inout sequence/any behavior with oversized return values
Issue 112: Semantics of CORBA_exception_id()"s return type
Issue 113: Contents of string literal exception identifier
Issue 114: Specification type on CORBA_ORB_object_to_string example
Issue 115: CORBA_BOA_set_exception() parameter issues
Issue 155: Support for efficient DII invocation (Section 17.7.1 CORBA 2.))
Issue 157: Entire section 14.1 should not be there (CORBA 14)
Issue 158: Confusion about ORB handling call to pseudo objects via DII
Issue 159: Order of arguments in C Language mapped operation
Issue 160: Type declaration
Issue 161: Out of bound value behaviour for _maximum and _length in sequences
Issue 162: Portably getting the value of the bounds of a sequence
Issue 163: Editorial
Issue 164: Order of parameters in the C mapping
Issue 165: Wrong placement of asterics in table
Issue 166: C Language header question
Issue 167: Pseudo-Object underspecification
Issue 168: Wrong order of parameters
Issue 169: Inappropriate information (Sect. 14.23. last paragraph
Issue 170: Reference to undefined term DIR (Section 14.24.1)
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 173: Argument order inconsistent (Section 14.25.2)
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 330: CORBA_string_alloc
Issue 331: Mapping for Aliases
Issue 332: Use of "objref_ptr"
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 2533: How to allocate storage for a basic type you wish to place in an any?
Issue 2534: Correct arguments to send multiple requests
Issue 2563: Content of an Any is a pointer to the type -- Issue
Issue 4341: Order of structure members
Issue 5778: OpaqueValue needs to be documented in the C Language mapping

Issue 53: C keywords (c_mapping-rtf)

Summary: There seems to be no provision for the possibility of C keywords appearing in IDL.

Summary: The C mapping advises avoiding the indiscriminate use of underscores in identifiers. To whom is this addressed? Should it be a more general restriction?

Summary: Section 14.3 of the C mapping says that interface definitions may not occur within the scope of module declarations. Doesn"t it mean "within the scope of another interface definition"?

Summary: In section 14-10 of the C mapping, it says that an ORB can use a struct to hold a union. Doesn"t this cause portability problems?

The spec has to allow that implementations can use something other than 

a C union because it's not possible to store everything in a C union.  

Because the spec requires that 'the union type' variable names and 

techniques be supported it does not cause portability problems when an 

application is moved from one to another implementation.   Since the 

internal format does not effect the format during transfer there is no 

interoperability impact.  

Summary: Section 14.11 of the C mapping introduces a release flag hidden inside the C struct; however, that struct is completely specified and leaves no bit for that flag. How does this work?

The section introduces a release flag but it does not put the flag inside 

the C struct.  The section states "the location of this release flag is 

implementation dependent."  Since the flag is only accessible via defined 

interfaces it location is not significant.

Summary: The fact that a sequence of longs is to be mapped into a struct is very confusing.

There does not seem to be any alternative approach.  Since C does not 

have a sequence primitive the implied parameters, i.e. max length, 

current length and pointer to data, must be put some where and a struct 

seems like the obvious answer. 



Fix typo

The IDL code

       Typedef CORBA_long FRED; 

       Typedef sequence <FRED,10> FredSeq; 

is commented to be C code.  Change /*  C  */ to be // IDL

Summary: The C mapping allocation procedures (T__alloc()) don"t allow for malloc"ing space for both the header struct and the values in one call.

It does not seem like the requested operation should provide.  There are 

cases where the combined operation would be wrong.  Therefore two 

operations would have to be specified. That would be a change to 

existing implementations, which are not supported very actively now.  I 

doubt such a change would be implemented.

Summary: It would be useful if CORBA_string_alloc() took an "optional" second argument which would be the string value to initialize the new string to, since ANSI C does not have strdup().

same as for Issue 109.

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: CORBA_exception_id() returns a pointer to the character string indentifying the exception. It would be nice to explicitly say that this is the same string defined in 14.14.

Summary: Section 14.14 calls for a string literal which "uniquely identifies this exception type", but does not specify any rules for generating such identifiers.

This does not seem to be an interoperability issue in that standard 

exceptions are defined and user exceptions have meaning only in the 

context of applications that understand both sides of the generation and 

reception of the exception.

Summary: On p. 14-24, the example of CORBA_ORB_object_to_string seems to have the CORBA_environment parameter in an unexpected position. Is this intentional? And what about the example on 14-28?

 closed issue

Summary: Who owns the parameters "exceptname" and "param" to CORBA_BOA_set_exception? Shouldn"t that routine take a second CORBA_Environment parameter to signal errors in its operation?

The sections on the POA have replaced the text related to the BOA and 

the POA text has no equivalent text.

Summary: Sun wants to ensure that DII interface permits implementations that support invocations without consulting the interface repository as intended by CORBA.

It's not clear what part of the spec is being addressed. It's not clear what 

version of the spec was involved with the reference to section 17.7.1.   

The newest version June 1999 puts the text related to DII in section 1.27 

and 1.28.  The text is effectively the same as that used in the CORBA 2.1 

at Section 17.26 and 27.   Neither section says that an implementation 

must use the IR as the means to resolve DSI or DII requests.

Summary: Entire section should not be here.It"s relevant to all potential language mappings. It should be moved to an appendix, since it is not a normative part of the specification

This is now section 1.1 and subparagraphs.  The text is not really part of 

the C language mapping and further it is not completely correct for the C 

Language mapping.   The errors show up where the text use examples 

and always makes a statement like " for example, the C mapping might 

define..." where in latter parts of the document we do define the actual 

mapping.  The other language mappings that I checked do not have an 

equivalent section.

Summary: Par. 14.1.8 indicates that ORB may handle calls to pseudo-objects via DII specially. This spec. should indicate that DII can"t be portably used for pseudo-object references.

Summary: Order of arguments to C Language mapped operations seems to have changed from CORBA 1.2. Order must remain the same. Order must be used consistently throughout this specification .

Summary: Section 14.5. ISO C permits declaration of anonymous structures when type is being defined. From a coding style perspective it"s better to require use of defined type names

It's not clear what spec version and paragraph is being addressed.  

Further it's not clear how a style issue should be addressed in the spec.

Summary: Section 14.11. Para 6 indicates error to set _length or _maximum member larger than specified bound. Say "If the _length and _maximum members are set to a value larger than specified...."

This is now section 1.11 in the June 1999 edition and the sentence still 

exists.  In full the sentence in question reads  "For bounded sequences, it 

is an error to set the _length or _maximum member to a value larger than 

the specified bound."  The issue seems to be suggesting that the spec 

would be clearer or more complete if we stated a problem and then went 

on to state the consequence of the error. However, the consequences of 

the error can be well defined.



Replace 

sentence with:

If the _length or _maximum members are set to values that are larger 

than the size of a bounded sequence or larger than the allocated space 

for a unbounded buffer then the result is undefined behavior.

Summary: Section 14.11: It"s not clear how a portable application could know value of bound of sequence. It"s specified in PIDL but is not represented in generated C header

It not clear what a C language mapping could do to provide this 

information.  The C++ language mapping simply states that maximum() 

for a bounded sequence will always return the  bound, but they can make 

that happen via the class.  The C language could do likewise, accessing 

the _maximum parameter will return the sequence bound but, that would 

only be true if the application had not at some point changed the bound.

Summary: Section 14.13: Para 6 Change "For an array T..." to "An array T..."

Summary: Section 14.15: Bullet 2 indicates that last parameter to each operation is an output parameter..Inconsistent with lead sentence, CORBA 1.2, and not reflectedin rest of doc.

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: Example CORBA_ORB_object_to_string function shows CORBA 1.2 function argument ordering. This is inconsistent with text in sect. 14.15. Spec must be internally consistent.

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: Paragraph refers to "DIR". This term has not been recently defined in the specification.

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: C signature for example4_op5 as well as CORBA_BOA_set_exception have the environment parameter in the wrong place

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: Editorial issue: The definition on page 14-15 is given as char* CORBA_string_alloc(CORBA_unsigned_long_len); The return type should be "CORBA_char*".

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: Nothing defines what an "objref_ptr" is. This was presumably pasted in from C++ mapping which has a T_ptr concept. Stop using this term in the C mapping or define it

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.
 

Summary:  Under the C mapping how do you allocate storage for a basic type
      you wish to place in an any.
 
      Consider inserting a long into an Any.
 
      Do you do this: solution 1
 
      any->_type = TC_long;
      any->_value = CORBA_alloc(sizeof(CORBA_long));
 
      or this: solution 2
 
      any->_type = TC_long;
      any->_value = CORBA_long__alloc();
 
      One vendor argues that the text below supports solution 2. However
      as a long is not a constructed type solution 1 seems more natural.
 
      >From  "17.8 Mapping Considerations for Constructed Types" of CORBA 2.1
      specification:
 
      "For types whose parameter passing modes require heap allocation,
      an ORB implementation will provide allocation functions. These types
      include variable-length struct, variable-length union, sequence, any,
      string, wstring and array of a variable-length type. The return value
      of these allocation functions must be freed using CORBA_free(). For
      one of these listed types T, the ORB implementation will provide
      the following type-specific allocation function:
 
      T	*T__alloc();	    /*	C  */"
 
 

Summary: Additional Commentary:
 
      In tset/c/hdr/DII/ORB/send_multiple_requests.c,
      VSOrb 1.1.0 test examines our orb on the assumption that
      send_multiple_requests() is defined like the following.
 
      CORBA_Status CORBA_send_multiple_requests(
        CORBA_ORB	    orb,
        CORBA_Request	    reqs[],
        CORBA_long	    count,
        CORBA_Flags	    invoke_flags,
        CORBA_Environment    *env
      );
 
      But, according to section 4.3.2 of CORBA 2.1 specification,
      send_multiple_requests() is defined like the following.
 
      /* C */
      CORBA_Status CORBA_send_multiple_requests(
        CORBA_Request	    reqs[],
        CORBA_Environment    *env,
        CORBA_long	    count,
        CORBA_Flags	    invoke_flags
      );
 
 Section C - Interpretation Responses
 
 The Open Group Initial Response:
      An interpretation from OMG is required to determine whether Section
      4.3.2 or Section 17.17 of CORBA 2.1 is definitive.
 
 Consultants Initial Response:
      We believe Section 4.3.2 is incorrect according to the general
      C mapping rules (as are many of the other examples).  We are
      following rules defined in Section 17.17 which states that every
      function signature takes the object as the first parameter and an
      Environment object as the last parameter.
 
 Interpretations Subgroup Responses:
 

Summary: In PIN4O.00001 OMG have ruled that the content of an any is a
      pointer to the type. So a long in an Any looks like this;
 
      any ----> long
 
      But what about strings? As this type includes a pointer part
      itself the above rules would make the following appear to be the
      conformant case;
 
      any----> ptr to string -----> string  : option 1
 
      Having a pointer to a pointer is a bit unwieldy but appears to follow
      the rules. Collapsing this to simply a pointer to the str thus;
 
      any----> string : option 2
 
      is more natural for programmers but ambiguous within the spec.
 
      We would like to know which of these two options is correct.
 
 Section C - Interpretation Responses
 
 The Open Group Initial Response:
      This request is being sent for review by OMG.  We request that OMG
      rule which of the two options is correct or whether both are equally
      so.
 
 Consultants Initial Response:
      We recommend this request be sent to OMG for a binding interpretation.
 
      We recommend a PIN be granted to clarify the requirements for branding
      irrespective of which of the two options OMG selects.
 

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.