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 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 168: Wrong order of parameters
Issue 170: Reference to undefined term DIR (Section 14.24.1)
Issue 173: Argument order inconsistent (Section 14.25.2)
Issue 330: CORBA_string_alloc
Issue 332: Use of "objref_ptr"
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 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: 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: 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: Paragraph refers to "DIR". This term has not been recently defined in the specification.

Summary: C signature for example4_op5 as well as CORBA_BOA_set_exception have the environment parameter in the wrong place

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