Issue 68: Missing info about the semantics of ORB_init and OA_init (orb_revision) Source: (, ) Nature: Uncategorized Severity: Summary: 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. Resolution: Incorporate change in 2.3a and close issue. Revised Text: Add the following paragraph immediately following the next to last paragraph Actions taken: August 13, 1996: Received issue February 22, 1999: closed issue Discussion: End of Annotations:===== Return-Path: Sender: jon@floorboard.com Date: Tue, 01 Sep 1998 20:22:12 -0700 From: Jonathan Biggar To: orb_revision@omg.org Subject: Proposals for 68, 588, 911, 1753 [All of the textual locations are relative to the new CORBA 2.3 draft documents in the ptc/98-08-?? series.] --------------------------------------------------------------------------------- Issue 68: Missing info about the semantics of ORB_init and OA_init Proposal: Add the following text to the next to last paragraph of section 4.6: Before ORB_init returns, it will remove all strings that match the -ORB pattern described above from the argv parameter. --------------------------------------------------------------------------------- Issue 588: limited-length strings Proposal: Modify the bullets in 1.2.4.1 for strings and wide strings to read: 0 A string type, which consists of a variable-length array of characters (a null character is one whose character code is 0); the length of the string is a non-negative integer, and is available at run-time. The length may have a maximum bound defined. 0 Wide character strings, which consist of a variable-length array of (fixed width) wide characters; the length of the wide string is a non-negative integer, and is available at run-time. The length may have a maximum bound defined. --------------------------------------------------------------------------------- Issue 991: Operations to add to CORBA::ORB pseudo-objec Proposal: [Note I have expanded the SerializedEncoding IDL type to include version information, since we now have 3 versions of CDR!] The following operations should be added to the CORBA::ORB pseudo-object: module CORBA { interface ORB { ... typedef sequence SerializedData; typedef unsigned long SerializedFormat; const SerializedFormat ENCODING_CDR = 0; struct SerializedEncoding { SerializedFormat format; octet major_version; octet minor_version; }; SerializedData serialize(in Any data, in SerializedEncoding how); Any unserialize(in SerializedData data, in SerializedEncoding how); SerializedData serialize_value(in Any data, in SerializedEncoding how); Any unserialize_value(in SerializedData data, in SerializedEncoding how, in TypeCode tc); ... }; }; These operations provide a standard mechanism for serializing and unserializing the data in an any, along with hooks to support new encoding formats as they are needed. The type SerializedEncoding indicates the encoding mechanism to use to serialize and unserialize the data. The format field specifies what encoding rules to use when serializing the data, and the major_version and minor_version indicate what version of the encoding rules to use. The serialize and unserialize encode the TypeCode along with the value so that the serialized data is self contained. The serialize_value and unserialize_value version encodes the value without the TypeCode to save space, but a TypeCode must be supplied to unserialize the data. Since the serialized data may contain no indication of machine dependent issues such as byte order, the serialized data can only be guaranteed to correctly be unserialized on the same ORB. The IDL any type should be used to exchange information between ORBs. Data encoded using the ENCODING_CDR format will be encoded using CDR encapsulation format. --------------------------------------------------------------------------------- Issue 1753: Size of IDL char Proposal: Close without change. I've been thinking about this one, and I think the text is correct. The char type is an 8-bit quantity with an allowed range of 0-255. The storage size of a char is a language-binding issue, not a core issue. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Tue, 08 Sep 1998 10:52:48 -0400 From: Paul H Kyzivat Organization: NobleNet To: Jonathan Biggar CC: orb_revision@omg.org Subject: Re: Proposals for 68, 588, 911, 1753 References: <35ECB9E4.9987E4D6@floorboard.com> Jonathan Biggar wrote: [snip] > Issue 68: Missing info about the semantics of ORB_init and OA_init > > Proposal: Add the following text to the next to last paragraph of > section 4.6: > > Before ORB_init returns, it will remove all strings that match the > -ORB pattern described above from the argv parameter. As a preface, while well meaning, the way these parameters are handled is at best bizare. (No offense to Jonathan - he is just trying to explain it better.) The goal here is to make the matched parameters disappear. On the other hand, ORB_init is not responsible for the storage of these, so it isn't clear what it can do to make them disappear that won't cause damage, such as leaks. The obvious intent is that the argc/argv passed to main() be provided here, but there is no guarantee of that, nor are the rules for managing those standardized across platforms. The best thing I have been able to do here is to rearrange the parameters so that the matched ones are at the end of the argv array. Then adjust the count so that they are not included. This causes the least disruption for the presumed owner of the array while achieving the intended effect. There is a bigger problem here. Exactly which parameters match? Clearly something starting with "-ORB" matches. But what about a following parameter? Does a following parameter always belong (as a value) to the prior (switch) parameter? What if the following parameter begins with "-ORB"? What if it begins with "-"? This needs to be defined in a way that does not require the orb to have a list of the legal values of xxx in "-ORBxxx" because (I believe) switches specific to one orb are to be ignored by other orbs. Return-Path: Sender: jon@floorboard.com Date: Tue, 08 Sep 1998 09:27:44 -0700 From: Jonathan Biggar To: Paul H Kyzivat CC: orb_revision@omg.org Subject: Re: Proposals for 68, 588, 911, 1753 References: <35ECB9E4.9987E4D6@floorboard.com> <35F544C0.4383E3BA@noblenet.com> Paul H Kyzivat wrote: > > Jonathan Biggar wrote: > [snip] > > Issue 68: Missing info about the semantics of ORB_init and OA_init > > > > Proposal: Add the following text to the next to last paragraph of > > section 4.6: > > > > Before ORB_init returns, it will remove all strings that match the > > -ORB pattern described above from the argv parameter. > > As a preface, while well meaning, the way these parameters are > handled > is at best bizare. (No offense to Jonathan - he is just trying to > explain it better.) > > The goal here is to make the matched parameters disappear. On the > other > hand, ORB_init is not responsible for the storage of these, so it > isn't > clear what it can do to make them disappear that won't cause damage, > such as leaks. The obvious intent is that the argc/argv passed to > main() > be provided here, but there is no guarantee of that, nor are the > rules > for managing those standardized across platforms. We needed the text in the language independent description of ORB_init that states that parameters that are recognized by the ORB are removed from the argv sequence. For language bindings that use the standard mapping for an inout sequence for ORB_init, they use their standard mechanism for handling memory managment of inout sequences. For languages that use custom mappings, (C and C++ at least), the language mapping must define how ORB_init modifies its parameters. So I think the proposed resolution should stand for the ORB core language independent part. If you think the text for C or C++ needs some more explaination, those are more properly handled by the C/C++ RTF. > The best thing I have been able to do here is to rearrange the > parameters so that the matched ones are at the end of the argv > array. > Then adjust the count so that they are not included. This causes the > least disruption for the presumed owner of the array while achieving > the > intended effect. For C & C++, this is reasonable. Other packages, such as X windows, also does a similar thing: there are APIs defined that take argc and argv, and the APIs are defined to remove from argc and argv any parameters that are recognized by that package. It would probably be a good idea to specifically state in the C and C++ mappings what it means to "remove" the parameter. In this case, it just means to fiddle the pointers in the argv array, and decrement argc. > There is a bigger problem here. Exactly which parameters match? Clearly > something starting with "-ORB" matches. But what about a following > parameter? Does a following parameter always belong (as a value) to the > prior (switch) parameter? What if the following parameter begins with > "-ORB"? What if it begins with "-"? This needs to be defined in a way > that does not require the orb to have a list of the legal values of xxx > in "-ORBxxx" because (I believe) switches specific to one orb are to be > ignored by other orbs. Whether a -ORB parameter needs an additional argument is up to the ORB implementation. You do raise a good question of whether the ORB should consume all -ORB arguments whether or not it recognizes them. I don't have an opinion either way. Anyone else want to comment? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org Return-Path: Date: Tue, 08 Sep 1998 20:06:54 -0400 From: Paul H Kyzivat Organization: NobleNet To: Jonathan Biggar CC: orb_revision@omg.org Subject: Re: Proposals for 68, 588, 911, 1753 References: <35ECB9E4.9987E4D6@floorboard.com> <35F544C0.4383E3BA@noblenet.com> <35F55B00.93A73042@floorboard.com> Jonathan Biggar wrote: > > Paul H Kyzivat wrote: > > > > Jonathan Biggar wrote: > > [snip] > > > Issue 68: Missing info about the semantics of ORB_init and > OA_init > > > > > > Proposal: Add the following text to the next to last paragraph > of > > > section 4.6: > > > > > > Before ORB_init returns, it will remove all strings that match > the > > > -ORB pattern described above from the argv parameter. > > > > As a preface, while well meaning, the way these parameters are > handled > > is at best bizare. (No offense to Jonathan - he is just trying to > > explain it better.) > > > > The goal here is to make the matched parameters disappear. On the > other > > hand, ORB_init is not responsible for the storage of these, so it > isn't > > clear what it can do to make them disappear that won't cause > damage, > > such as leaks. The obvious intent is that the argc/argv passed to > main() > > be provided here, but there is no guarantee of that, nor are the > rules > > for managing those standardized across platforms. > > We needed the text in the language independent description of > ORB_init > that states that parameters that are recognized by the ORB are > removed > from the argv sequence. For language bindings that use the standard > mapping for an inout sequence for ORB_init, they use their standard > mechanism for handling memory managment of inout sequences. For > languages that use custom mappings, (C and C++ at least), the > language > mapping must define how ORB_init modifies its parameters. > > So I think the proposed resolution should stand for the ORB core > language independent part. If you think the text for C or C++ needs > some more explaination, those are more properly handled by the C/C++ > RTF. Sorry! I receive all of these things in the same mail folder. While the fact that this was addressed to the orb_revision list was staring me in the face, I was still just thinking C/C++. In the context this was proposed I agree with you. > > There is a bigger problem here. Exactly which parameters match? > Clearly > > something starting with "-ORB" matches. But what about a following > > parameter? Does a following parameter always belong (as a value) > to > the > > prior (switch) parameter? What if the following parameter begins > with > > "-ORB"? What if it begins with "-"? This needs to be defined in a > way > > that does not require the orb to have a list of the legal values > of > xxx > > in "-ORBxxx" because (I believe) switches specific to one orb are > to > be > > ignored by other orbs. > > Whether a -ORB parameter needs an additional argument is up > to > the ORB implementation. You do raise a good question of whether the > ORB > should consume all -ORB arguments whether or not it > recognizes > them. I don't have an opinion either way. Anyone else want to > comment? It has been my assumption that this was intended. This is at least implied by the reservation of all arguments that begin with -ORB. Otherwise, only the ones actually consumed by the orb in question would need to be reserved. But consuming arguments that are not understood cannot be done reliably if an unspecified number of following values need to be consumed. I would be happy to hear that the ORB may accept the ones it wishes, with whatever values it wishes, and reject any others as errors. Is this the way others interpret the spec? If need be I will submit another issue on this specific subject. Return-Path: X-Authentication-Warning: tigger.dstc.edu.au: michi owned process doing -bs Date: Wed, 9 Sep 1998 12:38:19 +1000 (EST) From: Michi Henning To: Paul H Kyzivat cc: Jonathan Biggar , orb_revision@omg.org Subject: Re: Proposals for 68, 588, 911, 1753 Content-ID: On Tue, 8 Sep 1998, Paul H Kyzivat wrote: > > Whether a -ORB parameter needs an additional argument is up > > to > > the ORB implementation. You do raise a good question of whether the > > ORB > > should consume all -ORB arguments whether or not it > > recognizes > > them. I don't have an opinion either way. Anyone else want to > > comment? > > It has been my assumption that this was intended. This is at least > implied by the reservation of all arguments that begin with -ORB. > Otherwise, only the ones actually consumed by the orb in question would > need to be reserved. > > But consuming arguments that are not understood cannot be done reliably > if an unspecified number of following values need to be consumed. Yes. The problem is caused by option arguments. Assume we have: a.out -ORBxxx yyy zzz If the ORB understands the -ORBxxx option, there is no problem. If -ORBxxx requires an option argument, the cleaned up vector becomes: a.out zzz If -ORBxxx doesn't require an option argument, it becomes a.out yyy zzz Either way, there is no ambiguity. However, if the ORB doesn't know the -ORBxxx option, it can't decide whether yyy is an option argument, or whether it is an ordinary argument. In other words, either of the following cleaned-up vectors is possible, and there is no way to know which one is right: a.out yyy zzz # If -ORBxxx doesn't have an option argument a.out zzz # If -ORBxxx does have an option argument > I would be happy to hear that the ORB may accept the ones it wishes, > with whatever values it wishes, and reject any others as errors. Is > this > the way others interpret the spec? If need be I will submit another > issue on this specific subject. Hmmm... I'm not sure whether that is the Right Thing. The alternative would be to state that anything not understood should be left alone, so only options that are known to the ORB are removed. Unfortunately, I'm not sure that's the Right Thing either... The problem is that the application is unlikely to be able to deal with -ORBxxx any better than the ORB itself. Overall, I suspect the best thing would be to throw BAD_PARAM from ORB_init() if argc/argv contains an unknown -ORBxxx option, so I agree with you Paul (gee, will miracles never cease? :-) Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Date: Mon, 21 Sep 1998 12:37:33 -0400 From: Paul H Kyzivat Organization: NobleNet To: Michi Henning CC: Jonathan Biggar , orb_revision@omg.org Subject: Proposal for 68 References: Michi Henning wrote: > > The problem is that the application is unlikely to be able to deal > with -ORBxxx any better than the ORB itself. Overall, I suspect > the best thing would be to throw BAD_PARAM from ORB_init() if > argc/argv contains an unknown -ORBxxx option, I think I have seen comments from others agreeing with this, yet I also see that Issue 68 is listed as having an agreed resolution. According to the issue archive, all is see proposed is: Proposal: Add the following text to the next to last paragraph of section 4.6: Before ORB_init returns, it will remove all strings that match the -ORB pattern described above from the argv parameter. That doesn't deal with this problem. As an alternative, I suggest that the last sentence of the second to last paragraph of section 4.6 be replaced with the following: Any -ORBid parameters and all other -ORB parameters in the arg_list that are of significance to the orb, together with any associated following value parameters, shall be removed from the arg_list before returning from ORB_init. If any -ORB parameters are present that are not of significance to the orb, the BAD_PARAM exception shall be raised. > so I agree with you Paul > (gee, will miracles never cease? :-) This is bound to happen by random chance every now and then. :) Return-Path: X-Authentication-Warning: fatcat.dstc.edu.au: michi owned process doing -bs Date: Tue, 22 Sep 1998 05:12:38 +1000 (EST) From: Michi Henning To: Paul H Kyzivat cc: Jonathan Biggar , orb_revision@omg.org Subject: Re: Proposal for 68 Content-ID: On Mon, 21 Sep 1998, Paul H Kyzivat wrote: > That doesn't deal with this problem. As an alternative, I suggest that > the last sentence of the second to last paragraph of section 4.6 be > replaced with the following: > > Any -ORBid parameters and all other -ORB parameters in the > arg_list that are of significance to the orb, together with any > associated following value parameters, shall be removed from > the arg_list before returning from ORB_init. If any -ORB > parameters are present that are not of significance to the orb, > the BAD_PARAM exception shall be raised. Being pure of thought, I agree with this proposal ;-) I'm not sure about the terminology. Calling this things "parameters" and "associated following value parameters" seems awkward, at least if we don't define these terms. I'm used to seeing the called "options" and "option arguments". Should we use those terms? Cheers, Michi. -- Michi Henning +61 7 33654310 DSTC Pty Ltd +61 7 33654311 (fax) University of Qld 4072 michi@dstc.edu.au AUSTRALIA http://www.dstc.edu.au/BDU/staff/michi-henning.html Return-Path: Date: Mon, 21 Sep 1998 16:16:26 -0400 From: Paul H Kyzivat Organization: NobleNet To: Michi Henning CC: Jonathan Biggar , orb_revision@omg.org Subject: Re: Proposal for 68 References: Michi Henning wrote: > > On Mon, 21 Sep 1998, Paul H Kyzivat wrote: > > > That doesn't deal with this problem. As an alternative, I suggest > that > > the last sentence of the second to last paragraph of section 4.6 > be > > replaced with the following: > > > > Any -ORBid parameters and all other -ORB parameters in > the > > arg_list that are of significance to the orb, together with any > > associated following value parameters, shall be removed from > > the arg_list before returning from ORB_init. If any -ORB > > parameters are present that are not of significance to the orb, > > the BAD_PARAM exception shall be raised. > > Being pure of thought, I agree with this proposal ;-) Hey, now there are two of us! > > I'm not sure about the terminology. Calling this things "parameters" > and "associated following value parameters" seems awkward, at least > if > we don't define these terms. I'm used to seeing the called "options" > and "option arguments". Should we use those terms? Doesn't matter to me. I was attempting to preserve the usage already present in the section. It uses the term "parameter" as well as "argument" to refer to these things. I admit to winging it with the "associated following value parameter" language. It could be more precise, but I am not sure how much detail we need to get into here. Ultimately this is going to be vendor specific, so I don't know how precise we need to be. Feel free to wordsmith this. ============== Now I want to raise another ambiguity in this same section. The last paragraph of 4.6 is pretty confusing: "The ORB_init operation may be called any number of times and shall return the same ORB reference when the same ORBid string is passed, either explicitly as an argument to ORB_init or through the arg_list. All other -ORB parameters in the arg_list may be considered on subsequent calls to ORB_init." 1) I *believe* that the provision for returning the "same" orb is intended to allow different portions of server code to access an initialized orb without having to pass the initial reference around globally. However I am not certain this is the only interpretation. 2) Consider a call to ORB_init with -ORBid in the arg_list. If I call it a second time with the *same* arg_list, the -ORBid argument will not be present the second time. What is to happen in this case? Is the result different if than if I pass an unaltered copy of the original arg_list? (I don't see any simple answer to this if the ORB_init is capable of supporting different values for ORBid.) 3) Contrast the following: orb_1 = ORB_init(argc,argv,""); orb_2 = ORB_init(argc,argv,""); orb_1->shutdown(0,0); orb_3 = ORB_init(argc,argv,""); Presumably orb_1 and orb_2 return references to the same orb. But is there any requirement that orb_3 be the same? (I think this should be explicitly undefined.) 4) What is meant by "all other ... parameters may be considered..."? If these parameters alter the behavior of the orb, is it permissible to ignore them if the orb is not shutdown at the time of the call? (I think this must be allowed.) 5) In (3), if the original argc/argv contained -ORB arguments, should they be considered during the initialization of orb_3? If so, how might this be expected to happen? (I think they should, and I have made this work with a hack, but am not happy with having to hack it. But it isn't clear to me how do do anything clean and reasonable without making major changes to the definition of ORB_init.)