Summary: 1. The label value corresponding to a default label should be
designated explicitly either as an ignored field whose size equals the
size for the discriminator type, as some value that does not coincide
with another label value, as reserverd for future use, or as absent
(Table 12-2 and page 12-16, "encoding the tk_union Default Case" of
IIOP 2.1).

No Data Available

Summary: Should the TypeCode equal operation compare the results of name() to determine TypeCode equality? Same question for member_name()

Duplicate of issue 665

Summary: The question is: What is the exact marshalling for an encapsulation
of a zero length sequence? (Service context is an encapsulation of a
sequence. CORBA 2.1, Section 10.6.7, page 10-22.)
While it may or may not be an ambiguity,
it does appear that ORB vendors differ in their interpretations, so
it might be important to clarify it.

closed, no revision required

Summary: Its not clear to me how octet indices used for alignment and for
TypeCode indirection offsets are calculated in the presence of
fragmentation. Different interpretations will prevent successful
interoperablity when fragmentation is used. IIOP 1.2 should clarify how alignment and TypeCode indirection work in the presence of fragmentation.

closed with revision

Summary: There are 2 changes:
1. add the request id to message fragments so that fragmentation is usable.
2. change the alignment rules so that message headers may be changed
without having to remarshal the body.
[ as an aside we"d really like to remove all the alignment rules so that
any"s no longer have to be double marshaled, but we don"t think its
possible to deal with all the details quickly ]
3. Add some more addressing information to request, locate_request,etc.

No Data Available

Summary: When a GIOP "LocateRequest" message is sent to a location service and it replies with OBJECT_FORWARD, can the IOR have a type_id equal to simply CORBA::Object rather than the true type id?

Closed with revised text

Summary: Static port # should not be mandated-unworkable.It would be nice if a "standard" IIOP port # was registered with IANA

closed with no revision required

Summary: section 7.2.5 names it "non_existent", while section 12.4.1 says that the GIOP protocol version is "_nonexistent".

resolved, close issue

Summary: There is a problem with marshalling of union TypeCodes where multiple discriminant values select the same arm of the union.

closed with revised text

Summary: It would be good if the request body of a LOCATION_FORWARD reply always started on an 8 byte boundary.

closed with revision from issue 901, 902

Summary: I think that there is a pervasive Typo in Appendix A of chapter 18.
A number of the PIDL classes include a member function _duplicate.
It should be declared as a static member function
with an argument; i.e. the pointer to be "duplicated".

No Data Available

Summary: C++ mapping in CORBA 2.1 has a typo in the array mapping (section 18.15 page 18-33).Same typo appears in orbos/97-05-15 in section 16.12 page 16-33. It would be nice to actually show the C++ definitions for the types F, V, and M. Find details in corresponding file

Fixed in CORBA 2.2 editing process

Summary: Section 14.29: The C mapping for list_initial_services is incorrect and should return a pointer to a sequence (example in corresponding archive file)

Fixed in CORBA 2.2 editing process

Summary: The definition of Any in C.3 is missing the no_copy flag in the class Any::from_string.

Fixed in CORBA 2.2 editing process

Summary: Should the Any extractor signature be (Any_ptr &) instead of (Any &)?

Fixed in CORBA 2.2 editing process

Summary: The following inserter is missing in the C++ spec: void operation <<=(Any &, Any *); // non-copying

Fixed in CORBA 2.2 editing process

Summary: Some IIOP implementations set the object pointers to nil object pointers, while others set them to nil pointers.

closed, no revision required

Summary: Add an additional enumeration to the ReplyStatusType (and
LocationStatusType) called LOCATION_FORWARD_PERM (and
OBJECT_FORWARD_PERM) that acts like the current LOCATION_FORWARD (and
OBJECT_FORWARD), but can be used as a hint by the client that it should
permanently discard the original IOR and replace it with the new IOR.

No Data Available

Summary: I"d like to suggest that for GIOP 1.2 that we add an additional requirement
that an eight byte alignment occur before the body of any message.
This allows for numerous optimizations that currently cannot be performed
because the alignment of the beginning of the bodies is not consistent.

No Data Available

Summary: In CORBA /IIOP 2.1, 12.3.2 OMG IDL Constructed Types, Fixed-Point Decimal Type Section it is unclear to me that where is the decimal point in the IDL Fixed Type Representation (Figure 12-3), how the scale information is represented in the format

close with no change: The scale information is in the IDL definition of the fixed-point type

Summary: Section 12.7.2 defines the type IIOP::ProfileBody_1_0, which is
supposed to be compatible with the type ProfileBody of earlier
versions of CORBA. Unfortunately, it has a different repository
ID, leading to incompatibilities.
Proposed change: Add two pragmas to section 12.7.2, inside
the module IIOP

No Data Available

Summary: Add a rule to CDR that allows an empty string to be marshaled as a four byte count of zero, followed by nothing. This change is backward compatible because a count value of zero is currently impossible.
For a structure with five simple data members, this reduces the size of the
TypeCode on the wire from 88 bytes to 60 bytes (32% saving).

No Data Available

Summary: Potential problem in determining whether CancelRequest message applies to the current message or a message that has already had a reply sent. Resolutions to this: (file)

closed with revised text

Summary: Work for transport level bridge that doesn"t need to understand full GIOP/IIOP protocol. Requirements: interoperability across network that doesn"t share commom transport protocol

accomodated by "NeedAddressingInfo" change

Summary: Section 4.1.2 p. 20 : Implementation needs to know whether it is byte-oriented or not, since CDR representation is different in each case. ORB expected to maintain table mapping of all codesets?

duplicate to closed issue 1096

Summary: Section 4.1 GIOP CDR Transfer Syntax: The spec should cover cases where TCS-W is byte-oriented or non-byte oriented

duplicate to closed issue 1096

Summary: Assuming a 1.1 server we must Reply using 1.o to Request sent from 1.o client. If we get request with junk revision (eg 2.2) we wil automatically send (1.1) MessageError, but connection is close

closed, accomodated by clarification of version semantics

Summary: If 1.1 client sends request to 1.0 server and tis causes 1.0 MessageError msf from serverthen 1.1 client must recognize MessageErrors from 1.o servers

accomodated by clarification of version semantics

Summary: Is there a standard by which you can identify whether incoming IOR is for an object reference in our ORB or not? Opaque object key could have same encoding in another ORB...Confusion

closed with no revision required

Summary: Callbacks in IIOP are to be implemented by getting the server to connect back to client and act as a client itself. If this could be changed it would really help from firewall perspective.

closed with no revision required

Summary: A response_expected setting should be added to a new "Fragment Header"(issue589) so that this setting may be delayed until the final fragment

issue closed, no change required

Summary: Fragment messages should contain fragment header which contains a Request ID to associate the fragment with given request message. Frgamented request could otherwise block connection until sent.

fixed, close issue

Summary: This negotiation adds 16 bytes to both request and reply messages. It"s overburdening an already obese message header scheme.

closed, no revision required

Summary: page 26 of ptc/97-01-01: replace "Code set negotiation is not....." with"Code set negotiation is performed on a per-request basis."

closed with no revision required

Summary: What should an ORB do when it gets a message with an unknown service context ID value?

closed with revision

Summary: 1.1 client may get 1.0 CloseConnection prior to first attemptto send Requests which it needs to recognize. Spec should clarify this.

closed with revised text

Summary: 2. I cannot locate where the definition of typecodes for unions with
members with multiple labels. The natural semantics with respect to
the member accessor operations on that typecode and the CDR
marshalling of that typecode would seem to be that the union
declaration is treated as if the member definition in question were
replicated once for each label.

No Data Available

Summary: What is the consensus for the notation to use for interfaces to objects
that are in the orb but not outside. We use to call them psuedo objects.
During the last talk I got the feel that there are three options:

1. //PIDL
2. "psuedo" keyword placed before "interface"
3. //locally constrained

No Data Available

Summary: What is the return type of parent(), short or long? The spec does not say whether the inherited ::y::y::z takes precedence, or whether it is ::x::z. The scope resolution rules don"t mention how to resolve such an ambiguity. The spec should be updated to state that ::x::z takes precedence (IDL example in corresponding archive "issue783")

Close noting that this has been explained in Revised Chapter 3.

Summary: Consider the following operation in the ORB pseudointerface:

TypeCode create_union_tc (
in RepositoryId id,
in Identifier name,
in TypeCode discriminator_type,
in UnionMemberSeq members)

Suppose that in some mapping this is invoked with the given arguments,
i.e. an id, a name, a discriminator_type, and members..
For concreteness, suppose that the id argument has the value
"IDL:foo/bar:1.0".

There are three main cases:<<Go to issue archive>>

Add clarification to section 10.6 that consistency of RepositoryIds with the IDL source or the IR i

Summary: On page 7-32, the 2.1 spec says about #pragma processing:
An IDL compiler must either interpret these annotations
as specified, or ignore them completely.
I don"t think this makes sense.
If the prefix pragma isn"t honored in one ORB, but used by another ORB,
the repository IDs will disagree for types generated from the same
IDL definition, but with different IDL compilers. This in turn means
that interoperability is destroyed.

See resolution of 999 , close issue

Summary: The describe() operation of the CORBA::Contained interface of the
Interface Repository is under-specified in CORBA 2.1. (section 7.5.3
on page 7-12). The text should add that the "kind" field of the returned
Description struct should give the DefinitionKind for the "most derived"
type of the object. Without this, the spec can be read as allowing
describe() to return a kind of dk_Typedef, or even dk_all!

incorporate the proposed clarification

Summary: There is a minor ambiguity here. Consider the case where the ORB cannot
make a reliable determination because the client-side run-time cannot
reach the implementation repository or the server. In that case, most
ORBs will raise a TRANSIENT or COMM_FAILURE exception. I can read the
above words in the spec to mean that a compliant implementation of
non_existent is allowed to hide the exception from me and return false
instead.
I suggest to amend the wording such that non_existent is obliged to propagate
any exception other than OBJECT_NOT_EXIST back to the caller.

Sugested text below , close issue

Summary: 1. Appendix B lists the CORBA Component IDs. This listing is
incorrect: Proposed resolution: Change Appendix B to correspond to the
main text.

Proposed resolution: Change Appendix B to correspond to the

Summary: the trader constraint language (page 16-98, 2.1 spec) defines a
character class "<other>". This class is used in the definition of
what characters may appear inside a string literal (on page 16-97).
The problem is that the definition limits the legal character values
that may appear in a string literal. Only character positions 0x1
to 0x7f are legal, anything else is illegal.

Replace section B.2.3 with corresponding text from the ISO Trader standard

Summary: What is the value member of what is returned by
CORBA::Contained::describe when invoked on a CORBA::ModuleDef object
corresponding to a top-level IDL module?

Incorporate change in 2.3 and close issue

Summary: This is a request to add an optional extension to IDL which would
permit an exception declaration to include a specification of the
superexception or superexceptions for a given exception, exactly the
same way superinterfaces may be specified when defining an interface.The advantage of this extension is that it (optionally) permits
interface designers to organize exceptions into categories, which can
help clarify the design of the exceptions.

close issue, resolved

Summary: The definition of IDL Repository IDs the example in the IFR chapter 7.6.6 indicates that prefixes when not set are not separated. Definition says that "typically" it is the prefix and scoped name separated with "/".

Fixed with sepcific example in section 10.6.5.2 in Rev 2.3

Summary: On the issue of making StructDef, UnionDef, and ExceptionDef inherit from container, would it be possible to introduce the depreciation of including anything other than members in these three types?

This issue appears to be a rehash of the essence of Issue 777 so I recommend that we close this wit

Summary: The definition of interface and object type in the Object Model
are imprecise, if not incorrect. [See section 1.2.5 of the Corba 2.1
spec (Aug 1997)]

Clarify as follows

Summary: the spec doesn"t say how I can reset a repository ID prefix back to nothing
after I have set it. Consider

#pragma prefix "dstc.edu.au"
interface foo {};
#pragam prefix "" // Attempt to reset prefix
interface bar {};

This doesn"t work with at least one ORB I have tried.

See resolution of issue 999 , close issue

Summary: Proposed IFR exceptions raised by destroy() and move(): exception DependencyExists {}; raised by create_* and move(): exception RIDAlreadyDefined {}; exception NameALreadyDefined {};

Incorporate changes in 2.3a and close issue.

Summary: Is it legal for a TypedefDef to contain another TypedefDef that is NOT mentioned in it"s "members" attribute? If not, should the IR spec explicitly forbid this?

resolved, issue closed

Summary: "Read Interface" section of 7.5.10: The second sentence is a typo. The StructDef as a whole can "contain" structs, unions, and enums. However, the members attribute is a CORBA IDL data type not a subtype of Container, and hence cannot "contain" anything in the sense used elsewhere in the IR spec. The sentence should be deleted

Remove the second sentence in section 8.5.10 of Rev 2.2

Summary: Section 18.4 "illegal characters": It should be clarified what corresponds to the concept of "illegal characters". On the othe hand, do we want to specify that ObjectIds generated by the POA should not include those "illegal characters?

No Data Available

Summary: Table 3-11 on page 3-26 shows wchar as al legal switch type for unions. The grammar on page 3-26 doesn"t have wchar as a legal switchtype. The same is true for grammar on page 3-13. Is wchar legal for union discriminator? Spec will need to be fixed

No Data Available

Summary: In the figure all the interfaces/skeletons/adaptors/stubs have either an Up-call or a Normal-call arrow or both with the exception of the Dynamic Skeleton which has neither

Add an Up-Call Arrow to the Dynamic skeleton box.

Summary: IDL should permit enum and octet constants.

The following changes add enum and octet constants to IDL:

Summary: IDL identifiers can contain non-ASCII alphabetic characters. None of the language maappings deals with this. To fix this restrict IDL identifiers to ASCII characters, digits and underscore

Since most of the implementation languages to which IDL is mapped do not accept non-ASCII character

Summary: The portability spec is silent on issue of native types with respect to typecodes, DII, DSI and Interface Repository. Issue should be addressed. (see archive for details)

Proposed resolution is to add representation of native type in the IR. Details below as proposed by

Summary: TypeCode equality is not very well-specified or portable.

Incorporate more complete specification as shown below:

Summary: The grammar mentions fixed point literals for constsnts on page 3-12. The corresponding section of the grammar on page 3-19 does not include <fixed_pt_literal> as a valid constant initializer

incorporate changes in 2.3 and close this issue and 1066.

Summary: When writing IDL, why is it not possible to have an exception declaration inherit from another exception? It"s possible to have an interface inherit another interface, so it seems logical to derive an exception class from an already declared exception area

close issue with no change with the above explanation.

Summary: The proposal is to define a new standard exception, called
EXTERNAL_ACCESS (the name is not important) that carries
an any value. Another alternative may be to re-define
the exception COMM_FAILURE so that it may carry an any in
addition to the existing minor and completed fields.

close no change in 2.4

Summary: Section 3.8.1: The syntax for basic types must be updated to include the adopted IDL type extensions.

Fixed in 2.2

Summary: Section 6.8: The create_exception() methos is declared outside any interface scope. It seems logical to move it to Container Interface along with other create_XXX() methods

Fixed in 2.2

Summary: Section 6.8: TCKind enum should be updated to include adopted IDL type extensions as follows: tk_longlong, tk_longdouble, tk_wstring, tk_wchar. Update DefinitionKind and PrimitiveKind enum

Close, fixed in 2.2

Summary: Section 3.2.3 and 3.2.4: It"s not said explicitly that an identifier may not differ from a keyword only in case since it differs only in case from a keyword

Fixed in 2.2+, Close

Summary: The section states that the <<and>> operands must be in the range 0 to 32. Should be changed to 0 to 64 to take new IDL type extensions into account

Close, Fixed in 2.2

Summary: Section 7.8: ; is missing from definition of attribute policy_type

Close, Fixed in 2.2

Summary: The IDL for interface Request does not match the C++ mapping. There are a series od add_arg methods in the mapping that should be added to the IDL.

Language mappings are allowed to have custom mappings for pseudo-interfaces.

Summary: Why does mapping ignore the sequence parameter specified in the IDL for the initialization service and split this single parameter into 2 separate ones in the mapping?

That is an artificat of C/C++ historical usage and is not a core issue. In general language mapping

Summary: The Object C++ mapping has an _request() method that is not in the IDL. This method should be added to the IDL

The Object::_request operation is an artifact of the C++ mapping and not generally applicable to ot

Summary: Only the C++ mapping defines string_free and string_dup. Why are these methods not present in other language mappings? If they are generally applicable they should be added to the IDL

They are C++ language specific helper functions, that is why they are in the C++ mapping section. T

Summary: Section 7.2.3: reference is made to OBJECT_NIL but there is no defined value for this. A value must be explicitly defined and typed

resolved, close issue

Summary: Why does Object have a get_implementation function instead of a readonly implementation attribute? (likewise for get_interface)

closed issue, no change

Summary: Does a service consist of single operation, or a collection of related operations, exceptions, types, and constants?

Cleaning up the use of the word service throughout the document does not seem to be an achievable g

Summary: One may expect it to be a reply or response.Reading chapters 1,4,5 makes clear that it is the entirety of an invocation of an operation, including request and response. Change possible soon?

Clarify the sense in which the term Request is used in section 1.2.2

Summary: There is confusion about effect of "prefix" pragma evident in the Interface Repository chapter. Whole notion of prefix should be explained more fully in section 6.6.1

Clarifying language has been incorporated in section 10.6.5.2 (old section 8.6.5.2) in Rev 2.3 adeq

Summary: What terminology should the core settle on? Interface inheritance with use of subtype/supertype? What about immediate and transitive versions of relationships?

resolved closed issue

Summary: Conforming compilers should ignore pragmas that are not defined. in this spec, and that they do not explicitly support. Portable applications should only use pragmas defined in this spec.

The proposal in the summary is unreasonably restrictive, and would disallow use of other pragmas i

Summary: The semantics of minor version number changes should be a requirement on conforming applications (objects).

That"s what the sections appears to say. close issue, no change

Summary: Para indicates that form of TypeCode constants might be implementation specific.Does that mean the contents of the TypeCode implementation as opposed to signature of programmer?

Offending language has been removed in Revision 2.3

Summary: Last sentence: It"s not clear under which conditions this is permitted. It"s permitted when a structure,union,enumeration or alias typecode wasn"t obtained from Interface Repository.

Fixed in 2.2 close no change

Summary: Sec 3.13 says enumerators don"t create a nested scope.Implication: 2 differnt enum types within same module can"t have same enumerator names. Flag following example as an error

issue closed, no change

Summary: New Idl types have been introduced to cover non-ISO code sets.Sec 5.4.1 indicates that where "generic strings" are required in a spec "wstring"should be used. Place holder in naming spec: Istring

not interpretable, closed

Summary: PIDL for this interface describes the exceptions that might be raised, but the text doesn"t define the conditions when all of those exceptions might occur. This must be addressed.

Fixed in 2.2 close no change.

Summary: It"s better to say "However, TypeCode "literals" shall have a representation such that they can be placed in C include files."

Offending sentence removed in the resolution of issue 73. This is the same as issue 73

Summary: Limited-length strings are missing from enumeration in section 1.2.4. Were they intended to go in "Basic Types" or the "Constructed types" section?

Incorporate change in 2.3a and close issue

Summary: Is it a mistake, in IDL grammar as given in CORBA 2.0, revised July 1996, that <octet_type> is not one of <const_type>s?

subsumed by issue 725

Summary: CORE contains specific language binding information which should be in a language binding chapter or in a new appendix

Such information now exists only in the way of examples of what a particular piece of pseudo-IDL me

Summary: Ther is sense in which an interface "includes" operations it inherits from its base interface.Does it also "include" types, constants, and exceptions?

close issue with annotation fixed in Rev 2.2+

Summary: These paras indicate that an error is returned if the ID already exists in the repository. What is the error and what happens of the IR supports versioning?

Superceded by 778

Summary: This Para indicates that the base_interface attribute can return an error if there are name conflicts. What error is returned?

Subsumed by 778

Summary: What does the describe operation return for this interface?

Add the sentence "The describe operation for an AttributeDef object returns an AttributeDescription

Summary: Para starts the description of the arguments for the lookup_name operation. It should stand out more instead of being intended in such a way that it looks like part of previous item"s description.

changed, close issue

Summary: Para descibes exclude_inherited argumentto the content operation. Format is poor, it"s not clear what the default setting for this argument might be (if any).

no change required, close issue

Summary: It"s not clear what lookup operation returns when it is successful. We can tell from the IDL, but it should be explicitly defined. We think it returns object reference to scoped name.

no change required, close issue

Summary: Para indicates that name attribute is changed to new_name, and version attribute is changed to new_version. If name already exists and IR doesn"t support versioning=error. What error?

Subsumed by 778 . Closed with that annotation

Summary: Para describes create_<type> operations. It indicates that there are errors returned under differing circumstances. Possible errors should be defined.

Superceded by 778

Summary: Para refers to the describe operation. This operation is part of the parent interface from which container interface is inherited.There should be a pointer to the parent interface

Close no change

Summary: Para indicates that the type member is ignored and that it should be set to TC_void. If it is ignored, why should it be set to anything?

Remove the phrase "is ignored" from the last sentence of section 8.5.9 rev 2.2

Summary: There should be a pointer to the list of simple types.

Replace the phrase "simple type( ..... )" by the phrase "primitive types allowed in a constant decl

Summary: This para and para 4 both describe a limiy_type argument. These should be described in the same way since they appear to have the same semantics

Incorporate resolution and close issue.

Summary: What other values of levels_to_search are legal? What happens if values other than those described are used?Is an exception raised? If so, what exception?

resolved, close issue

Summary: This Para refers to a PrimitiveDef. There should be a pointer to where this is defined.

In section 8.5.6 second para under Read Interface, add a cross reference to section 8.5.13 where Pr

Summary: This Para indicates that the type member is ignored and that it should be set to TC_void. If it is ignored, why should it be set to anything?

Incorporate resolution and close issue

Summary: Same as issue # 429 with respect to 6.5.4 Container Paragraph 5.

Incorporate resolution and close issue.

Summary: This initial Para of the Write Interface section indicates that an error is returned if an object with specified ID attribute already exists. Error should be specified.

Close with annotation as above.

Summary: Para indicates that IRs are not required to support simultaneous containment of multiple versions of the same named object. Required that IRs are able to handle multiple versions of objects

resolved, close issue

Summary: Write Interface description indicates that it is error to invoke destroy on a Repository or PrimitiveDef. Should state that behavior is undefined.

close issue, resolved

Summary: Spec reads " Property names are stored preserving their case, however names cannot differ simply by their case." This sentence should be deleted.

Propose to apply resolution as above and close issue in 2.3

Summary: X/Open believes there is no need to use different wording. They don"t believe that it is useful to indicate that mixing of methods might be allowed someday

In Section 5.2.2 Para 5 Rev 2.2 remove the word "currently" from the last sentence

Summary: Text reads:"Currently, only string values are supported by the context object." Sentence should be deleted, since PIDL requires that a string be the value provided

Propose apply resolution to rev 2.3 and close issue

Summary: X/Open recommends that this para is being reworded to require that applications call get_response after a send. Spec could also be modified to detect errors if response is not required

close issue, no change

Summary: Text reads " If the specified scope name is not found, an exception is returned." Error to be indicated must be specified. See objection for Paragraph 2.

See resolution of 404

Summary: Text indicates that "Value scope names are implementation-specific." Items not necessary for portable development of applications are unspecified,undefined.

Remove paragraph 4. Does not add any value to the spec.

Summary: The error to be returned must be specified.. Since a status is not required to be returned, it"s incorrect to say that error is returned. Exception is raised.

add text to sections 5.6.4, 5.6.5 and 5.6.7 stating what exceptions are raised under what condition

Summary: See comment on set_value in issue # 402

Propose apply resolution to rev 2.3 and close issue

Summary: The usage of len could easily lead to a situation where it was inconsistent with TypeCode through erronous usage. WOuld be great if standard System exception was available for this case.

Close no change in 2.3a

Summary: List of interceptors to be called during request and order in which interceptor will be called: Needs to be resolved by Alec Thomas but shouls also be moved to ORB RFT

close no change

Summary: Final Para describes the types of support interfaces that might be available in some implementations. These are not interesting for portable application develpoment.

no change necessary, issue closed

Summary: The exception to be returned is not specified. See objection for 4.6.4 get_values Paragraph 2.

see resolution of 404

Summary: This paragraph should be deleted, since it is not useful for an application programmer.

issue closed, no change

Summary: X/Open recommends that the specification is being modified to require DII functions to return a Status as an unsigned long. Implementations without return value return value:non-conforming

closed issue, resolved

Summary: This paragraph indicates that an exception is returned. See objection for 4.6.4 get_values Paragraph 2

see resolution of 404

Summary: Section 6.7 of the CORBA 2 spec constrains the representation of typecodes such that typecode "literals" can be placed in C include files. Is this meant?

The offending paragraph, which is now the para 3 of section 10.7, seems to not clearly state anythi

Summary: The text associated with ORB_init and OA_init does not specify what is done with the argv parameter that requires it to be inout.