Issues with the CORBA 2 C Mapping

From: Kim Coleman <KCOLEMAN@us.oracle.com>
Subject: T__alloc in C mapping

Is it the intent of the 2.0 C mapping that use of T__alloc functions are the 
only conformant way to allocate values of (variable-length) type T? Or can a 
conformant app also declare them on the stack? 
 
------------- 
Kim Coleman, kcoleman@us.oracle.com 
Oracle Media Net 
Oracle Corp., Redwood Shores, CA

From: Jonathan Biggar <jon@sems.com>
Subject: Re: T__alloc in C mapping

KCOLEMAN.US.ORACLE.COM wrote:
> 
> Is it the intent of the 2.0 C mapping that use of T__alloc functions are the
> only conformant way to allocate values of (variable-length) type T? Or can a
> conformant app also declare them on the stack?

No, a conformant app can declare a variable size type on the stack or
statically, or as a member of another type.  The only restriction
imposed by the binding is to use T_alloc & T_free, instead of new and
delete when you want to allocate these on the heap.

Jon Biggar
jon@sems.com

Date: Wed, 28 Aug 1996 10:59:33 PDT
From: Kim Coleman <KCOLEMAN@us.oracle.com>
Subject: Re: T__alloc in C mapping

At issue is the *C* mapping, not C++. There is no T_free, new, or delete. I 
should be more explicit about my concern: The release attribute of sequences 
and anys. 
 
If sequences/anys can be declared on the stack, there is no way to live up to 
the requirement that the default setting of the release attribute is FALSE; 
the spec is quite clear that calling CORBA_{sequence/any}_set_release is not 
required.  
 
In addition, it is difficult to efficiently implement release if it can 
neither be an exposed field of the struct (whose contents seem fully 
constrained by the mapping) nor hidden away during heap allocation. 
 
Since both sequences and any's have custom allocators, that seems the logical 
place to enforce the default behavior...but not if you don't have to use them.  
------------- 
Kim Coleman, kcoleman@us.oracle.com 
Oracle Media Net 
Oracle Corp., Redwood Shores, CA

Date: Thu, 29 Aug 1996 00:47:23 PDT
From: gautron@chorus.fr
Subject: T__free in C mapping

KCOLEMAN@us.oracle.com:
! At issue is the *C* mapping, not C++. There is no T_free, new, or delete

	I do agree to say that the C mapping is poorly designed concerning
	resource management functions. I think that we'll have to seriously
	re-consider that (and other parts of the mapping that are not clearly
	specified). Concerning release functions, CORBA_free seems to be a
	magic function releasing any type: that is merely impossible. BTW,
	the release function must be T__free (and not T_free), analogy to
	T__alloc.

-----------------------
Philippe Gautron,			email:	gautron@chorus.fr
HP (OSSD Europe)			# (+33) 1 30 64 82 00
c/o Chorus Systemes			Fax: (+33) 1 30 57 00 66
6 avenue Gustave Eiffel
78180 Montigny Le Bretonneux
FRANCE

Date: Mon, 9 Sep 1996 17:08:16 PDT
From: Bill Janssen <janssen@parc.xerox.com>
Subject: C Mapping:  all interfaces must be defined at global scope?

Section 14.3 says, ``All interfaces must be defined at global scope
(_no_ nested interfaces).''  This says, I believe, that interface
definitions may not occur within
the scope of module declarations.  Probably not what's intended? 
Shouldn't it say instead, ``No interface may be defined inside the scope
of another interface definition.''?  More or less what the parenthetical
remark says?

Bill

From: Bill Janssen <janssen@parc.xerox.com>
Subject: C mapping:  unions represented with either union or struct causes portability problems for class libraries
To: issues@omg.org
cc: orbos@omg.org, bomsig@omg.org

A somewhat esoteric problem:  In section 14-10, we find ``An ORB
implementation need not use a C union to hold the OMG IDL union element;
a C struct may be used instead.''  Doesn't this cause binary
compatibility problems, thereby rendering C-based class libraries using
OMG CORBA technology infeasible,and ceding that whole business sector to
Microsoft's COM?

Bill

From: Bill Janssen <janssen@parc.xerox.com>
Date: Tue, 8 Oct 1996 19:40:47 PDT

I suggest we change the mapping to say that IDL unions must be
represented in C with C union types.

Bill

Date: Thu, 31 Oct 1996 09:58:59 PST
From: Kim Coleman <KCOLEMAN@us.oracle.com>

While I have no serious problem with Bill's suggested resolution that 
IDL unions must be implemented as C unions, I don't believe you can 
assume the kind of binary compatibility suggested by this issue 
anyway. 
 
If you have a library of stubs, you'd better be using headers and/or 
stubs generated by the same ORB implementation. There is no binary 
compatibility among objects. Nor can you assume there is any among 
things like exceptions and the proposed solution to the sequence/any 
release problem: These structures will all have implementation  
dependent attributes. Admittedly, they're in the opaque portions of 
the data structures, but you still can assume binary compatibility 
with some other implementation. 
 
Before tightening this requirement, we should find out whether or not 
we're going to introduce backward compatibility problems. While this 
clearly wasn't a concern when the 2.0 mapping was done, it should have 
been. 

Date: Mon, 9 Sep 1996 17:12:51 PDT
Errors-to: "janssen@parc.xerox.COM".BitBucket@xerox.com
From: Bill Janssen <janssen@parc.xerox.com>
Subject: C mapping:  sequence release flag implementation?

In section 14.11, ``Mapping for Sequence Types'', we are introduced to a
mysterious release flag hidden inside the C struct representing a
sequence type, somehow.  Unfortunately, that C struct is completely
specified (in contrast to the CORBA_Environment struct, for example,
which is partially opaque), and contains no bit reserved for the release
flag.  In addition, the default value for the release flag must be
FALSE.  Since these sequence structs may be either stack or heap
allocated, the only reasonable way to preserve most of these required
semantics is to keep a hash table or list of sequence values for which
the release flag is TRUE.  Even this has the defect of ``flipping'' the
release flag from TRUE to FALSE when the sequence struct is assigned to
a variable of the appropriate type.  How is this supposed to work
correctly?

Bill

Submitter: Swee.Lim@Eng.Sun.COM (Swee Boon Lim)
Synopsis: C mapping for sequence
Severity: SERIOUS
Related Issues: none

[Sec 14.11 CORBA2.0]
Section D.11 presents the C mapping for sequence.  For performance
reasons, Sun prefers to embed the release flag in the sequence.
The example in page 121 becomes:

typedef struct {
	CORBA_unsigned_long _maximum;
	CORBA_unsigned_long _length;
	CORBA_long	    *_buffer;
	CORBA_boolean	    _release;
};

Examples on page 123 should be similarly revised.

This is a backwards compatible change except when a sequence is
declared with initializers, such as

vec10 x = { 10L, 0L, (CORBA_long *) NULL };

It should become

vec10 x = { 10L, 0L, (CORBA_long *) NULL, FALSE /* or TRUE */ }

Date: Mon, 9 Sep 1996 17:20:10 PDT
From: Bill Janssen <janssen@parc.xerox.com>
Subject: C mapping:  malloc problems with sequence types

One thing commonly useful with sequences is a function that allows one
to malloc space for both the header struct and the values in one call. 
However, the prescribed allocation procedures for sequences are only
T__alloc(), which doesn't take a `size' parameter, and
CORBA_sequence_T_allocbuf(), which doesn't allocated the header.

Personally, I'd change the T__alloc() def for sequences to take an
"unsigned long" parameter which would be an initial number of values to
allocate for the sequence.

Bill

Date: Thu, 31 Oct 1996 09:58:59 PST
From: Kim Coleman <KCOLEMAN@us.oracle.com>

I mostly agree with Bill's suggested resolution, except that I have 
a problem with bound sequences: It does not seem correct to be able 
to allocate a sequence buffer of arbitrary length if the sequence is 
constrained. 
 
Of course, you can always take a "buyer beware" stance, which in general 
seems to be what the C mapping does with bound sequences and strings. 

Date: Mon, 9 Sep 1996 17:18:56 PDT
From: Bill Janssen <janssen@parc.xerox.com>
Subject: C mapping:  confusing sequence example

In section 14-11, the sequence example

  typedef CORBA_long FRED;    /* C */
  typedef sequence<FRED,10> FredSeq;

is defined to be ``mapped onto struct {...} CORBA_sequence_long;''. 
First of all, isn't this gratuitously confusing?  Why isn't it stated as

  typedef long FRED;
  typedef sequence<FRED,10> FredSeq;

is ``mapped onto `typedef CORBA_long FRED;  typedef struct {...}
CORBA_sequence_long;  typedef CORBA_sequence_long FredSeq;'''?

Secondly, suppose another sequence type is defined thusly:

  typedef sequence<FRED,20> AnotherFredSeq;

Is another (somehow different) struct definition to be generated as
`typedef struct {...} CORBA_sequence_long;' that has different
semantics?  Won't this cause problems for the compiler :-?

Bill

Date: Tue, 10 Sep 1996 03:47:27 PDT
From: C.Wood@slh0633.wins.icl.co.uk
Subject: RE: C mapping: confusing sequence example

Yes, fundamental ones.

The alternative is only to define CORBA_sequence_long once, using the
first definition encountered. 

But consider if the IDL definitions are actually:

  typedef enum { X, Y, Z } Fred;
  typedef sequence<Fred, 20> FredSeq;

  typedef enum { A, B, C } Bert;
  typedef sequence<Bert, 20> BertSeq;

This will generate C definitions:

  typedef enum { X, Y, Z } Fred;
  typedef struct { ...., Fred* _buffer } CORBA_sequence_enum;
  typedef CORBA_sequence_enum FredSeq;

  typedef enum { A, B, C } Bert;
  typedef CORBA_sequence_enum BertSeq;

This works, but it doesn't half cause my C compiler to complain about 
mismatched types.

I'm lost as to what this part of the specification is trying to achieve.
Wouldn't it be much simpler for it to specify that the generated C definitions
in this case are:

  typedef enum { X, Y, Z } Fred;
  typedef struct { ...., Fred* _buffer } FredSeq;

  typedef enum { A, B, C } Bert;
  typedef struct { ...., Bert* _buffer } BertSeq;


Regards.

--
Chris Wood, 
ICL Object Software Labs, 
Observatory House, Windsor Rd, Slough, SL1 2EY, UK
mailto:chris_wood@iclnet.co.uk tel:+44-1753-604311

Date: Mon, 9 Sep 1996 17:04:44 PDT
From: Bill Janssen <janssen@parc.xerox.com>
Subject: C Mapping:  problems with underscores

In section 14.2 of the CORBA C mapping, there is an explanation of how
the C mapping for type names can easily be confused, due to the
permissibility of underscores in the IDL type names, and their similar
use in the C type names.  This section includes the statement, ``Due to
such ambiguities, it is advisable to avoid the indiscriminate use of
underscores in identifiers.''  To whom is this statement addressed?  The
user of the C mapping can't influence how the (perhaps COBOL-thinking)
designer, of the IDL he happens to have to use, used underscores. 
Shouldn't either the C mapping be fixed to not have this unfortunate
confusion, or the use of underscores in OMG IDL be eliminated or somehow
curtailed?

Bill

Date: Thu, 31 Oct 1996 09:58:59 PST
From: Kim Coleman <KCOLEMAN@us.oracle.com>

I do not believe it is reasonable to change the IDL definition at 
this point to preclude the use of underscores in identifiers. I don't 
think problems in the C mapping justify breaking existing IDL. 
 
If it really seems inappropriate, I'd favor striking the statement. 
On the other hand, it isn't entirely out of line either. I have users 
writing IDL and implementing servers exclusively in C. They certainly 
have control over the use of underscores in their own IDL, and they've 
learned the hard way just how difficult it is to unravel the mess made 
by underscores in IDL identifiers. I'd like to tatoo this warning across  
their foreheads. 

Date: Mon, 9 Sep 1996 17:23:26 PDT
From: Bill Janssen <janssen@parc.xerox.com>
Subject: C mapping:  inout sequence/any behavior with oversized return values?

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 originally supplied?  Is the value of _buffer dropped on
the floor?  (Wouldn't this lead to memory leaks?)  Is an error returned?

Bill

Date: Mon, 9 Sep 1996 17:21:27 PDT
From: Bill Janssen <janssen@parc.xerox.com>
Subject: C mapping:  suggested optimization for string duplication

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 for some wierd reason doesn't include the strdup()
function.  Optional in the sense that it could be NULL.

Bill

Date: Thu, 31 Oct 1996 09:58:59 PST
From: Kim Coleman <KCOLEMAN@us.oracle.com>

Rather than a second parameter on CORBA_string_alloc, why not just have 
a string dup operation? At the risk of drawing fire down on my head, 
this is what they did to the C++ mapping and I think it is entirely 
appropriate: 
 
  CORBA_char* CORBA_string_dup(const CORBA_char*); 

Date: Mon, 9 Sep 1996 17:25:50 PDT
From: Bill Janssen <janssen@parc.xerox.com>
Subject: C mapping:  semantics of CORBA_exception_id()'s return type?

In section 14.20, we find that ``CORBA_exception_id() returns a pointer
to the character string identifying the exception''.  This is presumably
the same character string defined (or, rather, left up to the
implementor's imagination) in section 14.14, but it would be nice to say
so explicitly.  Note that this string need have no obvious relationship
to, say, the name of the exception (though it ``could be'' the
repository-id of the exception).

Bill

From: Bill Janssen <janssen@parc.xerox.com>
Date: Tue, 8 Oct 1996 19:45:50 PDT

I suggest we add a sentence to section 14.20 which states that the
character string returned from CORBA_exception_id() is the same (in
the equal sense, not the eq sense) character string assigned as an
identifier for the exception in section 14.14 (whatever that string
may be).

Bill

Date: Mon, 9 Sep 1996 17:30:05 PDT
From: Bill Janssen <janssen@parc.xerox.com>
Subject: C mapping:  specification typo on CORBA_ORB_object_to_string() example?

On page 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 the top of page 14-28?  The
C signatures on page 14-29?

Bill

From: Bill Janssen <janssen@parc.xerox.com>
Date: Tue, 8 Oct 1996 19:46:43 PDT

I suggest we fix the typo by moving the environment parameter to the
end of the argument list.

Bill

Date: Mon, 9 Sep 1996 17:31:24 PDT
From: Bill Janssen <janssen@parc.xerox.com>
Subject: C mapping:  CORBA_BOA_set_exception() parameter issues

Who owns the parameters ``exceptname'' and ``param'' to
CORBA_BOA_set_exception?  Shouldn't that routine take a second
CORBA_Environment parameter as the last parameter to signal errors in
its operation?

Bill

Date: Mon, 9 Sep 1996 17:28:52 PDT
From: Bill Janssen <janssen@parc.xerox.com>
Subject: C mapping:  contents of string literal exception identifier?

Section 14.14 calls for a string literal which ``uniquely identifies
this exception type'', but doesn't specify any rules for generating such
identifiers.  From this, I assume that every ORB implementation may use
a different string for this purpose?

Bill

Submitter: Swee.Lim@Eng.Sun.COM (Swee Boon Lim)
Synopsis: Support for efficient DII invocation
Severity: CRITICAL
Related Issues: none

[Sec 17.7.1 Pg 17-10 CORBA2.0]
Section 4.7 describes the DII interface.

Sun would like to ensure that the DII interface permits implementations
that support invocations without consulting the interface repository 
(IFR) as originally intended by CORBA.  Clients who would like to 
avoid consulting the IFR, should be able to provide the same type 
information present in stubs to the DII interface.  This implies that 
the DII interface should permit DII clients to provide the typecodes 
for all parameters, contexts for the invoked method, and typecodes for 
all user exceptions that the method may throw.

Sun would like to add the following to the CORBA module:

pseudo interface ExceptionList {
	readonly attribute long count;
	void add(in TypeCode exc);
	TypeCode index(in long index) raises (Bounds);
	Status remove(in long index) raises (Bounds);
};

pseudo interface ContextList {
	readonly attribute long count;
	void add(in string exc);
	string index(in long index) raises (Bounds);
	Status remove(in long index) raises (Bounds);
};

pseudo interface ORB {
	...
	Status create_exception_list(out ExceptionList exc_list);
	Status create_context_list(out ContextList exc_list);
	...
};	

pseudo interface Request {
	...
	readonly attribute ExceptionList exceptions;
	readonly attribute ContextList   contexts;
	...
};

interface Object {
	...
	Status create_request2(
		in Context ctx,
		in Identifier operation,
		in NVList arg_list,
		in NamedValue result,
		in ExceptionList exc_list,
		in ContextList ctx_list,
		out Request request,
		in Flags req_flags
	);
	...
};

Note: ContextList and ExceptionList could be sequences.  However, 
      sequences are less efficient due to copying, especially when
      the same list of exceptions and contexts are used multiple times.
      Pseudo objects replace copying with reference counting.

Resolution: Adopt Sun's proposed solution, but also provide the same
functionality in the C mapping DII.  The details of the C mapping
changes are not yet worked out.

Status: C++ mapping is fixed.  C mapping is not.

Date: Sun, 6 Oct 1996 23:39:50 PDT
From: "P Gardner" <p.gardner@x400.icl.co.uk>
Subject: representation of "string" values in an "any"

A question I asked a while back to which I received no replies:
in the C mapping what is the representation of a "string" in the
_value field of an any? "char *" or "char **"? To be consistent
with the representation of other types it would seem "char **"
was more applicable. However, usage of this requires an "_alloc"
function for "char **". Cheers, Paul
================================================================================

IssueID: OMGCXX1.2-C-001-M
OMG Issue #: 157, 158
Submitter: XOpen
Synopsis: Entire section 14.1 should not be there
Severity: MEDIUM
Related Issues:

Description: This entire section should not be here. It is relevant to
all potential language mappings, not just the C language mapping. It
should be moved to an appendix, since it is not a normative part of
the specification.

Resolution: Proposed fix: Editorial change, move whole section to appendix
Status: Open

IssueID: OMGCXX1.2-C-002-C
OMG Issue #:
Submitter: XOpen
Synopsis: Confusion about ORB handling call to pseudo objects via DII
Severity: CRITICAL
Related Issues: 

Description: Paragraph 14.1.8 indicates that the ORB may handle calls
to pseudo-objects via the DII specially. Actually, X/Open believes
that these calls must be handled portably or the DII cannot be used to
access pseudo-objects by applications. This may be the intent. In that
case, this specification should indicate that the DII cannot be
portably used for pseudo-object references.

Date: Thu, 31 Oct 1996 09:58:59 PST
From: Kim Coleman <KCOLEMAN@us.oracle.com>

This is not an issue for the C mapping. As already suggested in another 
issue, section 14.1 should be axed. However, it's a very good question 
for orbos. 

IssueID: OMGCXX1.2-C-003-C
OMG Issue #: 159
Submitter: XOpen
Synopsis: Order of arguments in C language mapped operation 
Severity: CRITICAL
Related Issues: 

Description: The order of arguments to C Language Mapped operations
seems to have changed from CORBA 1.2. Further, this change is handled
inconsistently throughout this specification. X/Open believes that the
argument order must remain the same to preserve compatibility with
applications written against the previous X/Open and OMG
specification. Further, the order must be used consistently throughout
this specification (Sec 14.3 and other sections)

Resolution: Proposed fix: make the order consistently to be the 1.2 one.

Date: Thu, 31 Oct 1996 09:58:59 PST
From: Kim Coleman <KCOLEMAN@us.oracle.com>

I agree, the movement of the context and environment parameters to 
the end of par list seems entirely gratuitous. 
 
However, I have a real problem with moving it back again: User whiplash. 
Bad enough to tell them they have to change their code once. Intolerable 
to tell them to put it back the other way. Or are there no 2.0 compliant 
C mappings right now? I certainly expect to have one before this issue 
gets resolved. 

IssueID: OMGCXX1.2-C-004-E
OMG Issue #: 160
Submitter: XOpen
Synopsis: Type declaration
Severity: ENHANCEMENT
Related Issues: 

Description: (Section 14.5) ISO C permits the declaration of anonymous
structures when a type is being defined. This creates a type that can
be used when declaring identifiers without declaring a corresponding
structure (or union) that can also be used when declaring identifiers.
From a coding style perspective, it seems better to require the use of
the defined type names by not even creating the corresponding named
structure. 

IssueID: OMGCXX1.2-C-005-M
OMG Issue #: 161
Submitter: XOpen
Synopsis: Out of bound value behavior for _maximum and _length in sequences
Severity: MEDIUM
Related Issues: 

Description: (Section 14.11) Para 6   indicates that it is an error to
set the _length or _maximum member to a value larger than the
specified bound. This should probably say "If the _length and _maximum
members are set to a value larger than the specified bound, the
behavior is undefined."

Resolution: Proposed fix: Add the sentence to the para.

IssueID: OMGCXX1.2-C-006-M
OMG Issue #: 162
Submitter: XOpen
Synopsis: Portably getting the value of the bounds of a sequence
Severity: MEDIUM
Related Issues: 

Description: (Section 14.11) Para 6  It is not clear how a portable
application could know the value of the bound of a sequence. It is
specified in the PIDL, but does not seem to be represented in the
generated C header. This information must be made available to the
portable application.

IssueID: OMGCXX1.2-C-007-M
OMG Issue #: 163
Submitter: XOpen
Synopsis: Editorial
Severity: MEDIUM
Related Issues: 

Description: (Section 14.13) Para 6 Change "For an array T ..." to "An
array T..."

Resolution: Proposed fix: Make it so

IssueID: OMGCXX1.2-C-008-C
OMG Issue #: 164
Submitter: XOpen
Synopsis: Order of parameters in the C mapping
Severity: CRITICAL
Related Issues: 

Description: (Section 14.15) This section indicates that "all
operations declared in an interface have additional leading parameters
preceding the operation-specific parameters." This is as it was
specified in CORBA 1.2, and is fine from X/Open's perspective.
However, bullet "2" indicates that the last parameter to each
operations is an output parameter. this is inconsistent with the lead
sentence, inconsistent with CORBA 1.2, and is not reflected in the
rest of the document. We believe this text should be changed back to
the way it was in CORBA 1.2

Resolution: Proposed fix: Make things consistent with the way it is
described in bullet 2, i.e. additional parameters are trailing
parameters, not leading parameters.

IssueID: OMGCXX1.2-C-009-M
OMG Issue #: 165
Submitter: XOpen
Synopsis: Wrong placement of asterisks in table
Severity: MEDIUM
Related Issues: 

Description: (Section 14.19) The asterisks in this table are meant to
indicate that the item is a C language pointer. They should not be
superscripted. 

Resolution: Proposed fix: Make it so

IssueID: OMGCXX1.2-C-010-M
OMG Issue #: 166
Submitter: XOpen
Synopsis: C language header question
Severity: MEDIUM
Related Issues: 

Description: (Section 14.22) This paragraph indicates that all IDL
compilers will generate a C language header. Does this mean that the C
Language is required to be supported by all CORBA implementations

Resolution: Proposed fix: The paragraph is bogus. Reword it to say
that IDL compilers in ORBs that support the C language mapping
generate such files. Of course all IDL compilers do not generate C
headers! 

IssueID: OMGCXX1.2-C-011-C
OMG Issue #: 167
Submitter: XOpen
Synopsis: Pseudo-Object underspecification, scope restrictions
Severity: CRITICAL
Related Issues: 

Description: (Section 14.23) This section indicates that ORBs may
restrict the scope of legal operations on pseudo-objects. It is
imperative that the minimal subset of operations be defined so that
portable applications know what they can rely upon.

IssueID: OMGCXX1.2-C-012-C
OMG Issue #: 168
Submitter: XOpen
Synopsis: Pseudo-Object underspecification
Severity: CRITICAL
Related Issues: 
Description: Section 14.23
The example of CORBA_ORB_object_to_string function
shows the CORBA 1.2 function argument ordering. this is inconsistent
with the text in section 14.15, but is the order that XOpen prefers.
In any event the specification must be internally consistent.

Resolution: Proposed Resolution: Make it consistent with he general
order i.e. implicit parameters come last.

IssueID: OMGCXX1.2-C-013-M
OMG Issue #: 169
Submitter: XOpen
Synopsis: Inappropriate information about pseudo-objects
Severity: MEDIUM
Related Issues: 
Description: Section 14.23 last para
This information on implementation strategies for pseudo-objects is
not relevant to application portability, and may serve to confuse
application developers. It should be removed or appropriately
annotated as Guidance to ORB implementors.

Resolution: Proposed Resolution: Make it so, annotate it as such.

IssueID: OMGCXX1.2-C-014-C
OMG Issue #: 170
Submitter: XOpen
Synopsis: Reference to undefined term DIR
Severity: CRITICAL
Related Issues: 

Description: Section 14.24.1 
This paragraph refers to "DIR". Unfortunately, this term has not been
recently defined in the specification.

Resolution: Proposed Resolution: In the last bullet just before the
beginning of Sec 14.24.1 add "(DIR)" immediately following the term
"Dynamic Implementation Routine", thus defining DIR.

IssueID: OMGCXX1.2-C-015-C
OMG Issue #: 171
Submitter: XOpen
Synopsis: Parameter memory freeing problem
Severity: CRITICAL
Related Issues: 

Description: Section 14.24.1 para 6 This para indicates that all the
parameter memory is freed as appropriate when the DIR returns. It is
not clear by whom the memory is freed. If the DIR frees the memory,
then change the wording as appropriate.  This whole paragraph is
pretty bad. The term "appropriate" needs to be replaced by better
explanation of what happens.

IssueID: OMGCXX1.2-C-016-M
OMG Issue #: 172
Submitter: XOpen
Synopsis: implementation hints not specification
Severity: MEDIUM
Related Issues: 

Description: Section 14.24.2 last para
This paragraph describes the strategy an implementation will use for
determining an exception TypeCode. This information is not relevant to
application developer. It should be marked as Guidance to Implementor.

Resolution: Proposed Resolution: Make it so.

IssueID: OMGCXX1.2-C-017-C
OMG Issue #: 173
Submitter: XOpen
Synopsis: argument order inconsistent
Severity: CRITICAL
Related Issues: 

Description: Section 14.25.2
C signature for example4_op5 as well as CORBA_BOA_set_exception have
the environment parameter in the wrong place.

Resolution: Proposed Resolution: make ev the last parameter.

IssueID: OMGCXX1.2-C-018-C
OMG Issue #: 174
Submitter: XOpen
Synopsis: what happens when set_exception called more than once?
Severity: CRITICAL
Related Issues: 

Description: Section 14.25.2
It is not clear what happens if CORBA_BOA_set_exception is called more
than once for a given object invocation. this should be specified.

Resolution: Proposed Resolution: Last invocation values are recorded
and all others discarded?

IssueID: OMGCXX1.2-C-019-C
OMG Issue #: 175
Submitter: XOpen
Synopsis: confusing presentation in 14.25.4
Severity: CRITICAL
Related Issues: 

Description: Section 14.25.4
This is very confusing. It refers to a "third case", but there are no
real cases described, and there are only two examples. What are the
cases that this paragraph refers to?

IssueID: OMGCXX1.2-C-020-C
OMG Issue #: 176
Submitter: XOpen
Synopsis: inconsistent parameter name and order
Severity: CRITICAL
Related Issues: 

Description: Section 14.26, 14.27
In the definition of CORBA_ORB_init the Environment parameter comes
last, AND it uses env instead of ev for its name, unlike all other
examples. Same inconsistency in the definition of
CORBA_ORB_list_initial_services and CORBA_ORB_list_initial_references
on pg 14-33.

Resolution: Proposed Resolution: Position is fine, change name to ev.

Date: Thu, 31 Oct 1996 09:40:18 PST
From: "KCOLEMAN.US.ORACLE.COM" <KCOLEMAN@us.oracle.com>
Subject: C: Bound seq buffer allocation

What if the user calls T_allocbuf for a bound sequence with a length 
that doesn't match the sequence constraint? Does this go undetected? 
  
If the allocbuf functions continue to be tied to sequence types which 
pay no attention to bounds, then the answer is presumably yes. 
  
But if a more radical change is made, regarding the problems addressed 
in issue 108, then T_allocbuf for a bound sequence should not have a 
length parameter - you get back a buffer of the constrained size. 
 
Of course, this requires the user to be aware of whether the sequence is 
constrained or not, which is not exactly obvious in the C mapping, as 
previously noted elsewhere. 
 
------------- 
Kim Coleman, kcoleman@us.oracle.com 
Oracle Media Net, Dist. Object Technology Group 
Oracle Corp., Redwood Shores, CA

Date: Mon, 21 Oct 1996 23:40:10 PDT
From: Matt Stillerman <matt@oracorp.com>

The spec contains mutually inconsistent examples (pages 14-11 and
14-13).  Page 14-11 says that

  typdef sequence<long, 10> vec10;     /* IDL */

is to be mapped this way:

  typedef struct {                    /* C */
   CORBA_unsigned_long  _maximum;
   CORBA_unsigned_long  _length;
   CORBA_long          *_buffer;
  }  vec10;

However page 14-13 suggests that the C structure MUST be named 

   CORBA_sequence_long

instead, and must be enclosed in #ifdef ... #endif in such a way that
multiple declarations will not cause compiler problems.   Taking this
second approach, it seems reasonable, to also generate this typedef:

 typedef CORBA_sequence_long vec10;     /* C */

However, the specification does not explicitly require this declaration.
If this last declaration is required, then the spec should say so.

Date: Mon, 21 Oct 1996 23:40:10 PDT
From: Matt Stillerman <matt@oracorp.com>

Continuing with the vec10 example, it seems that we have declared two
new types: vec10 and CORBA_sequence_long.  Are these distinct types?  Of
course, as pure C types, they are not distinct.  I want to know, for
instance, whether they would have distinct typecodes and distinct
entries in the Interface Repository.  Also, even if they are distinct,
am I REQUIRED to generate both entries when I compile the above IDL?

A similar issue pertains to declarations of arrays and strings: are we
declaring two new types (one of which is an alias), or just one.

BTW: If the answer is that there is just one new type, then could
someone provide and example in which an "alias" typecode arises?

Date: Thu, 31 Oct 1996 09:50:31 PST
Subject: C: Mapping for Aliases
From: Kim Coleman <KCOLEMAN@us.oracle.com>

I believe the mapping for IDL typedefs was somehow dropped between CORBA 1.2 
and 2.0. We all know what it is, but it should still be explicitly stated. 
Restoring the text from the 1.2 mapping is probably sufficient. 

Date: Mon, 21 Oct 1996 23:40:10 PDT
From: Matt Stillerman <matt@oracorp.com>

The spec mentions two allocation functions for sequences of "T":

   CORBA_sequence_T * CORBA_sequence_T__alloc();             /* C */
   T * CORBA_sequence_T_allocbuf(CORBA_unsigned_long len);

Now, these declarations had better be inside the same (or similar)
#ifdef ... #endif as the struct typedef.  If it is spelled out
explicitly in one case, why not in the other?

We have to generate definitions for those functions, as well.  However,
this raises the question of where to put those definitions.  If we put
them in with all of the other allocation funtions that we are
generating, then, the linker will complain about multiple definitions in
the following case: if two unrelated IDL typedefs (IDL-compiled
separately) declare the same sequence type and are both linked into the
same program.  Shouldn't the spec offer some guidance on this issue,
since it explicitly describes how to handle the related header file
issue?

BTW: It would be nice if we could be consistent in the number of
underscores which separate "T" from "alloc" and "allocbuf".  Note, also,
that CORBA_string_alloc and CORBA_any_alloc each use only one underscore
for this separation, in contradiction to the general rule (p 14-10).

Date: Mon, 21 Oct 1996 23:40:10 PDT
From: Matt Stillerman <matt@oracorp.com>

Are we also supposed to declare and define allocators for the new
sequence type?  For instance, coming back to the orignal example, are we
supposed to have these functions?

  vec10 * vec10__alloc();                       /* C */
  long  * vec10_allocbuf();

Is the following acceptable, required, or forbidden?

                                                    /* C */
#define vec10__alloc CORBA_sequence_long__alloc
#define vec10_allocbuf CORBA_sequence_long_allocbuf

Date: Thu, 31 Oct 1996 09:37:40 PST
From: Kim Coleman <KCOLEMAN@us.oracle.com>
To: issues@omg.org
Subject: C: Seq buffer allocation
Cc: c-rev-wg@omg.org

Section 14.11 specifies the generation of a buffer allocator for each 
sequence type of the form: 
  
  T* sequence_T_allocbuf(CORBA_unsigned_long len); 
  
If sequence types map together the way 14.11 implies (e.g. all aliases 
of a sequence of CORBA_long map to the same type, bound or not) and 
these allocators are tied to the fundamental sequence type, there can be 
no single point of definition and it is extremely difficult to implement 
correctly. 
  
If the allocator is tied instead to the alias, we need to define what 
happens when there is no alias, such as when the sequence is a struct 
field.  Do you get an allocator in that case? You don't really need one, but 
how about a buffer allocator? You still potentially need that. 

Date: Mon, 21 Oct 1996 23:40:10 PDT
From: Matt Stillerman <matt@oracorp.com>

When a sequence occurs as an anonymous (local) type in a struct,
union, etc, how should this be treated.  For example:

  struct  foobar {               /* IDL */
    sequence baz;
  };

Is it permissable, forbidden, or required to invent a type to represent
"sequence" ?   Alternatively, this could compile directly to: 

  typedef struct {                 /* C */
    struct {
      CORBA_unsigned_long _maximum;
      CORBA_unsigned_long _length;
      CORBA_long         *_buffer;
    }   baz;
   }   foobar;

However, trying to associate a release flag with that embedded sequence
seems to cause extreme distress, no matter how you try to do it.

Date: Mon, 21 Oct 1996 23:40:10 PDT
From: Matt Stillerman <matt@oracorp.com>

In the "vec10" example, the struct which is declared is:

   CORBA_sequence_long

Why is it not CORBA_sequence_CORBA_long?  What is the precise rule by
which these names are constructed?  For instance, which of these would
be correct:

     CORBA_sequence_InterfaceDef  or 
     CORBA_sequence_CORBA_InterfaceDef

Another related confusion: We are told to construct this type name with
the ultimate base type of the sequence element.  Examples are given to
show how the type of the sequence elements must be unwound (e.g.
CORBA_sequence_sequence_long), yet there is no general rule for how do
this and when to stop.  For instance, how would you map this:

  typedef sequence<string<10>> yax;

Date: Mon, 21 Oct 1996 23:40:10 PDT
From: Matt Stillerman <matt@oracorp.com>

When MUST the _buffer of a sequence be allocated with "_allocbuf"?
For instance:

  - always.
  - whenever the release flag is TRUE.
  - whenever the sequence elements contain secondary storage.
  - whenever it is an out, inout, or return.

When must it NOT be so allocated?

Date: Thu, 31 Oct 1996 09:49:20 PST
From: "KCOLEMAN.US.ORACLE.COM" <KCOLEMAN@us.oracle.com>
Subject: C: Use of "objref_ptr"

Nothing defines what an "objref_ptr" is. This was presumably pasted in 
from the C++ mapping which has a T_ptr concept. 
 
We should either stop using this term in the C mapping or define it. 

Date: Thu, 31 Oct 1996 09:40:18 PST
From: Kim Coleman <KCOLEMAN@us.oracle.com>
Subject: C: Bound seq buffer allocation

What if the user calls T_allocbuf for a bound sequence with a length 
that doesn't match the sequence constraint? Does this go undetected? 
  
If the allocbuf functions continue to be tied to sequence types which 
pay no attention to bounds, then the answer is presumably yes. 
  
But if a more radical change is made, regarding the problems addressed 
in issue 108, then T_allocbuf for a bound sequence should not have a 
length parameter - you get back a buffer of the constrained size. 
 
Of course, this requires the user to be aware of whether the sequence is 
constrained or not, which is not exactly obvious in the C mapping, as 
previously noted elsewhere. 

Date: Thu, 31 Oct 1996 09:38:43 PST
Subject: C: Seq buffer deallocation
From: Kim Coleman <KCOLEMAN@us.oracle.com>

Sequence buffers are allocated separately from the sequences which 
contain them, so presumably they can be released separately as well. 
  
Is this the job of the omnipotent CORBA_Free? And by what additional 
mystical powers does it deduce how many elements need to be released? 
  
It seems unreasonable to require CORBA_Free (or anything else) to perform 
a deep free on a sequence buffer when it can have no notion of how many 
slots in the buffer are actually occupied. Only in the context of a 
sequence object can you know how many elements need releasing. 
  
Perhaps there should be a free function for sequence buffers which takes 
as argument the entire sequence, but releases only the buffer (and sets 
the sequence length back to 0). 

Date: Thu, 31 Oct 1996 09:48:29 PST
From: Kim Coleman <KCOLEMAN@us.oracle.com>
Subject: C: Release flag & returned data

I think there is already an issue similar to this for the C++ mapping. 
The mapping should be explicit about how the release flag interacts 
with inout, out, and return parameters. 
  
Page 14-12 says that only the owner of a sequence (e.g. the caller) 
may set the release flag. Now consider a sequence buffer off the stack. 
I set the release flag to false and pass the sequence as an inout 
parameter. As a consequence of the call, the callee (or the ORB) 
replaces the sequence buffer. If the release flag remains unchanged, 
the caller must check to see if the buffer changed in order to know 
whether or not he actually has to release the buffer. 
  
I think it makes more sense to reset it to TRUE so that the user can still  
call CORBA_free on the sequence and the right thing will happen whether the  
buffer was replaced or not. 
  
Similarly for return and out parameters. One can take the position that 
the flag takes the default FALSE value (which seems unwise to me), or 
that it should always be TRUE in these cases because the callee 
(probably the ORB, in practice) has allocated the memory for you and so  
is reasonably required to release it. 

Date: Thu, 31 Oct 1996 09:55:41 PST
From: Kim Coleman <KCOLEMAN@us.oracle.com>
Subject: C: Exception id name

A long standing pet peeve of mine is the loose specification of 
the #define generated for an exception id. Specification by example 
is never a good idea. 
  
Is the form of the #define: 
  
    ex_<namespace-qualifiers>_<exception-name> 
or: 
    <namespace-qualifiers>_ex_<exception-name> 
  
So, for some exception E in module M, is it "ex_M_E" or "M_ex_E"? 
 
I don't want to break things - I'm content with existing practice (assuming it 
is consistent :-). But the specification should be more explicit. 

From: Kim Coleman <KCOLEMAN@us.oracle.com>
Date: Thu, 31 Oct 1996 09:52:16 PST
Subject: C: CORBA_string_alloc

Purely an editorial issue. The definition of CORBA_string_alloc on page 14-15 
is given as: 
 
  char* CORBA_string_alloc(CORBA_unsigned_long len); 
 
The return type should be "CORBA_char*". 

Date: Thu, 7 Nov 1996 17:01:33 PST
From: Matt Stillerman <matt@oracorp.com>
Subject: Argument Passing, cases 3 and 6

Table 22, page 14-20 of the C mapping lists argument passing cases. This
question pertains to cases 3 and 6.   In both of these cases the value
is either an out parameter or a return value.  

The caller must allocate a pointer and pass it (by reference).  The
callee must allocate some storage and adjust the pointer to refer to it.
Upon return, the caller must call CORBA_free on any returned value.

Now, both of these cases also say that the callee may not return a null
pointer.  In case of error, etc, the callee must still provide a valid
pointer. 

Questions: When the returned value of the Environment indicates that an
error has occured is the caller still obligated to call CORBA_free on
"outs" and "returns"?  Is the callee still obligated to provide a
pointer to which CORBA_free can meaningfully be applied?

Discussion: If the answer to the second question is "yes", then notice
the following difficulty: At the beginning of the client stub function,
a legal value is allocated for each instance of cases 3 or 6.  Then, if
a problem develops later that forces an early exit, the problem is
recorded as an exception in the environment, and it is OK to return.

However, if an error occurs in that initial allocation, our client stub
function has NO RECOURSE but to return a NULL.  Of course, tricks can be
played with static storage, but notice that CORBA_free will have to
recognize all of these and treat them specially.

Suggestion:  For cases 3 and 6, "It is always legal for the callee to
return a null pointer. The caller is responsible for freeing any
returned storage with CORBA_free if the returned pointer is non-null,
regardless of the exception status of the operation."