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 */"

urgent resolution, issue resolved

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

Fixed in CORBA 2.2 editing process

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:

urgent resolution....issue closed

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

replace sentence

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

close

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.

Fixed by Portability submission

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

Fixed in CORBA 2.2 editing process

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*".

Fixed in CORBA 2.2 editing process

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

Fixed by Portability Submission

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

add sentence

Summary: Paragraph refers to "DIR". This term has not been recently defined in the specification.

Fixed in CORBA 2.2 editing process

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 .

Fixed by Portability submission

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.

Fixed by Portability submission

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.

Replace sentence to clarify

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().

Close with no change

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?

Close with no change

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"?

resolved and closed

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.

close – paragraph is deleted

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

delete section

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?

POA update eliminated conditions - close

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?

Fixed by Portability submission

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?

Close with no change

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

close

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.

Close with no change

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.

Close with no change

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

Close with no change

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

resolved and closed

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?

resolved

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.

urgent resolution, issue closed