Issue 2533: How to allocate storage for a basic type you wish to place in an any? (c_mapping-rtf) Source: (, ) Nature: Uncategorized Issue Severity: Critical Summary: Summary: Under the C mapping how do you allocate storage for a basic type you wish to place in an any. Consider inserting a long into an Any. Do you do this: solution 1 any->_type = TC_long; any->_value = CORBA_alloc(sizeof(CORBA_long)); or this: solution 2 any->_type = TC_long; any->_value = CORBA_long__alloc(); One vendor argues that the text below supports solution 2. However as a long is not a constructed type solution 1 seems more natural. >From "17.8 Mapping Considerations for Constructed Types" of CORBA 2.1 specification: "For types whose parameter passing modes require heap allocation, an ORB implementation will provide allocation functions. These types include variable-length struct, variable-length union, sequence, any, string, wstring and array of a variable-length type. The return value of these allocation functions must be freed using CORBA_free(). For one of these listed types T, the ORB implementation will provide the following type-specific allocation function: T *T__alloc(); /* C */" Resolution: urgent resolution, issue resolved Revised Text: Resolution: OMG has selected solution 2. Additional information: In a future CORBA version the the text in section 19.8 of CORBA 2.2 (section 17.8 of CORBA 2.1) will be changed to better illustrate the existing words. The following existing paragraph seems to cover the question, if the type for an any is being allocated to the heap. For types whose parameter passing modes require heap allocation,an ORB implementation will provide allocation functions. These types include variable-length struct, variable-length union, sequence, any, string, wstring and array of a variable-length type. The return value of these allocation functions must be freed using CORBA_free(). For one of these listed types T, the ORB implementation will provide the following type-specific allocation function: T *T__alloc(); /* C */" To clarify the paragraph for type any value we will add the following text. To initialize the fields of an any with type T where T is a CORBA basic type, a T_alloc() operation shall be utilized. For example, an any containing a CORBA_long that was allocated to the heap would be initialized by: any->type = TC_long any_>value = CORBA_long__alloc( ); If the CORBA basic type value for the any was not allocated from the heap then the type specific allocator would not be used. Actions taken: March 12, 1999: received issue August 4, 1999: closed issue Discussion: End of Annotations:===== X-Sender: andrew@emerald.omg.org Date: Fri, 12 Mar 1999 16:37:29 -0500 To: Juergen Boldt , Richard Soley , Jon Siegel From: Andrew Watson Subject: OMG review of req.1.O.00009 From: Jenny Wilkinson Subject: OMG review of req.1.O.00009 To: ogomgorb@opengroup.org Date: Fri, 12 Mar 1999 13:39:38 +0000 (GMT) Reply-To: Jenny Wilkinson Precedence: list Date: 12 March 1999 To: ogomgorb@opengroup.org Dear OMG Technical Director (or appointee), In accordance with Section 4.4 of the Policies and Procedures of the OMG Technical Process, this notification is a request for an URGENT clarification of a specific issue. Please direct this to the appropriate RTF, or if no appropriate RTF is currently active, the OMG Architecture Board. As agreed, The Open Group has proposed specific options for the possible clarification. As Technical Director (or his appointee) you are able to propose other specific wording for the clarification to the committee (either the RTF or the AB). The committee is then at liberty to vote on the proposed clarification or to propose other clarifications. The issue for clarification is attached below in the standard Open Group formal interpretation request format which is used in the Open Group anonymous review process. The final clarification by OMG agreeing or disagreeing with the recommended options by the Open Group set out in Section C 'The Open Group Initial Response' will be inserted in the 'Interpretations Subgroup Responses:' part of Section C of the form. The Final Decision reflects this in Section D. The Technical Director or RTF Chair is requested to respond to The Open Group at (ogomgorb@opengroup.org within 10 working days, by 25 March 1999 **************************************************************************** INTERPRETATION REQUEST DOCUMENT TOG Reference: req.1.O.00009 Component: CORBA Section B - Interpretation Request Details Version/Release: VSORB 1.1.0 Testset: iiop//all Test No: 0 Waiver Reason: Grey area in the Specification Test Results: not available Additional Commentary: The issue is: Under the C mapping how do you allocate storage for a basic type you wish to place in an any. Consider inserting a long into an Any. Do you do this: solution 1 any->_type = TC_long; any->_value = CORBA_alloc(sizeof(CORBA_long)); or this: solution 2 any->_type = TC_long; any->_value = CORBA_long__alloc(); One vendor argues that the text below supports solution 2. However as a long is not a constructed type solution 1 seems more natural. >From "17.8 Mapping Considerations for Constructed Types" of CORBA 2.1 specification: "For types whose parameter passing modes require heap allocation, an ORB implementation will provide allocation functions. These types include variable-length struct, variable-length union, sequence, any, string, wstring and array of a variable-length type. The return value of these allocation functions must be freed using CORBA_free(). For one of these listed types T, the ORB implementation will provide the following type-specific allocation function: T *T__alloc(); /* C */" Section C - Interpretation Responses The Open Group Initial Response: An interpretation is requested from OMG. Consultants Initial Response: We recommend this request be sent to OMG for a binding interpretation of the govering specification. Interpretations Subgroup Responses: Section D - The Open Group Final Response: ************************************************************************ Jenny Wilkinson T H E Conformance Administrator O P E N Apex Plaza, Forbury Road, Reading RG1 1AX, UK G R O U P Mailto:j.wilkinson@opengroup.org Ph: +44 118 950 8311 x2273 WWW: http://www.opengroup.org Fx: +44 118 950 0110 'Motif, OSF/1, UNIX and the "X Device" are registered trademarks and IT DialTone and The Open Group are trademarks of The Open Group in the US and other countries' ************************************************************************ X-Sender: andrew@emerald.omg.org Date: Fri, 12 Mar 1999 18:03:03 -0500 To: tom_barker@omg.org, c_mapping-rtf@omg.org From: Andrew Watson Subject: Issues 2533 & 2534 classified as urgent Cc: issues@omg.org Dear Tom and members of the C mapping RTF, As you may have seen, we have been sent a couple of clarification requests by The Open Group. We've categorised these as C revision issues and classified them as urgent, which according to section 4.4.1.5 of the P&P means that OMG must respond with a resolution within two weeks. I'm appending the relevant section of the P&P to this message, but broadly speaking, the procedure for urgent resolutions is: 1. Once OMG staff has decided they're urgent issues, they're filed in the ordinary way. 2. Staff provides a proposed resolution (see below). If the RTF for some reason does not come to a decision on resolving the issues, staff submit a resolution, and absent any other contributions, it's likely to be this one. 3. You have two weeks to discuss and vote on a resolution in the normal way. 4. Two weeks from today (Friday 26th March), we will pass back to the Open Group the result of your deliberations (or, in the unlikely event you haven't voted on a resolution, a staff proposal). Here are the staff proposed resolutions: For issue 2533 (TOG Reference: req.1.O.00009), staff proposes that allocating longs in Anys using CORBA_alloc be considered standard (solution 1): any->_type = TC_long; any->_value = CORBA_alloc(sizeof(CORBA_long)); For issue 2534 (TOG Reference: req.1.O.00010), staff proposes that the definition of send_multiple_requests() in section 4.3.2 be ruled in error, and be changed to align with the rules section 17.17. If you have any questions on the urgent resolution process, please get in touch with me. Regards, Andrew Andrew Watson Tel: +1 508 820 4300 x111 VP Technology Fax: +1 508 820 4303 Object Management Group, Email: andrew@omg.org 492 Old Connecticut Path, Lat/Lon: 42.3122 N 71.3927 W Framingham, MA 01701, USA http://www.omg.org/~andrew ----------------------------------------------------------------- 4.4.1.5 Urgent Issues In response to urgent requests for clarifications to a specification ("Urgent Issues"), the OMG shall provide clarifications of specific issues. [Issues may arise that require interpretation or clarification of a specification in a very short period of time. For example, there may be disputes over interpretation during the course of conformance testing in the context of a branding program, or urgent clarifications required by a vendor during product implementation. Resolution needs to occur within a very short period of time (approximately 2 weeks), and should result in modifications on a point-by-point basis.] Urgent Issues shall be directed to the OMG Technical Director (or his appointee), who will determine whether the issue is appropriate for urgent resolution, and if so direct it to the appropriate F/RTF. If no appropriate F/RTF is currently active, the Architecture Board will be responsible for resolving the issue. The Technical Director (or his appointee) will propose specific wording for the clarification to the committee (either the RTF or AB). The committee is then at liberty to vote on the proposed clarification or to propose other clarifications. The issue is deemed closed when a particular clarification has been accepted by a poll of the F/RTF members. If a period of two weeks has passed from the receipt of the issue by the Technical Director and no clarification has been accepted, the Technical Director (or his appointee) will determine an appropriate clarification. [A clarification (in the sense used here) typically eliminates an ambiguity by narrowing the possible interpretations of a specification when there are multiple, incompatible interpretations. In cases where a specification is not logically consistent, a clarification may also render a part of a specification void or add new content, only inasmuch as it is necessary to make the specification consistent. This process must never be used to extend a specification's functionality. The deployment of the Architecture Board in this role is intended as a backstop, a last resort in case an appropriate F/RTF is not active. The Architecture Board should by no means become the "normal" vehicle for resolving issues of this nature. It is the responsibility and duty of the Technology Committees to charter F/RTFs for Adopted and Available Specifications and maintain their readiness to respond as needed. It will most likely be the case that committee discussions and polls on urgent issues will be conducted electronically. OMG staff will maintain appropriate email and document exchange mechanisms to facilitate this process.] Resolutions of Urgent Issues will be formulated and maintained as isolated revisions to the specification, identified by sequential natural numbers and made publicly available. Any clarifications produced by this process shall be incorporated into the final recommendation produced by the F/RTF. Should there not be an appropriate F/RTF, or if the F/RTF does not produce a recommendation before its delivery deadline, any clarifications produced in this manner will automatically and collectively constitute a recommendation of revision. Once a clarification has been accepted, it should not be revisited by the F/RTF during the current revision cycle. [The prohibition against revisiting a clarification is not intended to shackle the F/RTF, but to give clarifications generated by this process some stability. The requirements of branding programs are the primary motivation for this process. An Urgent Issue that alters a branding test suite may affect the implementation of shipping, branded software products, requiring one or more vendors to alter their products to conform to the specification as clarified. It is reasonable for vendors to expect that the clarification will not be arbitrarily reversed simply because the balance of opinion in an F/RTF shifts for some reason (e.g., a change in membership) before its final revision proposal is recommended to the parent Technology Committee. The need for stability is balanced against the need for TC approval. It is possible for the TC to reject the recommendation of an TF (and thus, a set of clarifications), but our assumption is that the TC understands the consequences of such a decision and would only do so under extraordinary circumstances. As an example: If a specification's current revision is numbered 2.1, clarifications will be identified separately, such as "clarification 1 of revision 2.1", and so on. When an F/RTF produces its revision recommendation (either explicitly or by default), the clarifications will be folded into the overall revision, resulting in revision 2.2. If the F/RTF fails to produce a recommendation, OMG staff will collect clarifications into a revision recommendation. ] From: Jeffrey Mischkinsky Subject: Re: Issues 2533 & 2534 classified as urgent To: andrew@omg.org (Andrew Watson) Date: Fri, 12 Mar 1999 16:33:41 -0800 (PST) Cc: tom_barker@omg.org, c_mapping-rtf@omg.org, issues@omg.org Andrew, It might be helpful in the future if "omg staff", which I suppose is the long-suffering and over-worked person currently manifested as yourself, provided a bit of the rationale for his or her recommendations. I personally agree with your suggestion on #1, and will probably agree with #2, but i have to do my due diligence and go look at the referenced sections first. thx, jeff 'Andrew Watson' writes: > > Dear Tom and members of the C mapping RTF, > > As you may have seen, we have been sent a couple of clarification > requests > by The Open Group. We've categorised these as C revision issues and > classified them as urgent, which according to section 4.4.1.5 of the > P&P > means that OMG must respond with a resolution within two weeks. > > I'm appending the relevant section of the P&P to this message, but > broadly > speaking, the procedure for urgent resolutions is: > > 1. Once OMG staff has decided they're urgent issues, they're filed > in the > ordinary way. > > 2. Staff provides a proposed resolution (see below). If the RTF for > some > reason does not come to a decision on resolving the issues, > staff submit > a resolution, and absent any other contributions, it's likely to > be this > one. > > 3. You have two weeks to discuss and vote on a resolution in the > normal > way. > > 4. Two weeks from today (Friday 26th March), we will pass back to > the Open > Group the result of your deliberations (or, in the unlikely > event you > haven't voted on a resolution, a staff proposal). > > Here are the staff proposed resolutions: > > For issue 2533 (TOG Reference: req.1.O.00009), staff proposes that > allocating longs in Anys using CORBA_alloc be considered standard > (solution > 1): > > any->_type = TC_long; > any->_value = CORBA_alloc(sizeof(CORBA_long)); > > For issue 2534 (TOG Reference: req.1.O.00010), staff proposes that > the > definition of send_multiple_requests() in section 4.3.2 be ruled in > error, > and be changed to align with the rules section 17.17. > > If you have any questions on the urgent resolution process, please > get in > touch with me. > Regards, > > Andrew > Andrew Watson Tel: +1 508 820 4300 > x111 > VP Technology Fax: +1 508 820 4303 > Object Management Group, Email: andrew@omg.org > 492 Old Connecticut Path, Lat/Lon: 42.3122 N > 71.3927 W > Framingham, MA 01701, USA > http://www.omg.org/~andrew > > > ----------------------------------------------------------------- > > 4.4.1.5 Urgent Issues > > In response to urgent requests for clarifications to a specification > ("Urgent Issues"), the OMG shall provide clarifications of specific > issues. > > [Issues may arise that require interpretation or clarification of a > specification in a very short period of time. For example, there may > be > disputes over interpretation during the course of conformance > testing in > the context of a branding program, or urgent clarifications required > by a > vendor during product implementation. Resolution needs to occur > within a > very short period of time (approximately 2 weeks), and should result > in > modifications on a point-by-point basis.] > > Urgent Issues shall be directed to the OMG Technical Director (or > his > appointee), who will determine whether the issue is appropriate for > urgent > resolution, and if so direct it to the appropriate F/RTF. If no > appropriate F/RTF is currently active, the Architecture Board will > be > responsible for resolving the issue. The Technical Director (or his > appointee) will propose specific wording for the clarification to > the > committee (either the RTF or AB). The committee is then at liberty > to vote > on the proposed clarification or to propose other > clarifications. The > issue is deemed closed when a particular clarification has been > accepted > by a poll of the F/RTF members. If a period of two weeks has passed > from > the receipt of the issue by the Technical Director and no > clarification > has been accepted, the Technical Director (or his appointee) will > determine an appropriate clarification. > > [A clarification (in the sense used here) typically eliminates an > ambiguity by narrowing the possible interpretations of a > specification > when there are multiple, incompatible interpretations. In cases > where a > specification is not logically consistent, a clarification may also > render > a part of a specification void or add new content, only inasmuch as > it is > necessary to make the specification consistent. This process must > never be > used to extend a specification's functionality. > > The deployment of the Architecture Board in this role is intended as > a > backstop, a last resort in case an appropriate F/RTF is not > active. The > Architecture Board should by no means become the "normal" vehicle > for > resolving issues of this nature. It is the responsibility and duty > of the > Technology Committees to charter F/RTFs for Adopted and Available > Specifications and maintain their readiness to respond as needed. > > It will most likely be the case that committee discussions and polls > on > urgent issues will be conducted electronically. OMG staff will > maintain > appropriate email and document exchange mechanisms to facilitate > this > process.] > > Resolutions of Urgent Issues will be formulated and maintained as > isolated > revisions to the specification, identified by sequential natural > numbers > and made publicly available. Any clarifications produced by this > process > shall be incorporated into the final recommendation produced by the > F/RTF. > Should there not be an appropriate F/RTF, or if the F/RTF does not > produce > a recommendation before its delivery deadline, any clarifications > produced > in this manner will automatically and collectively constitute a > recommendation of revision. Once a clarification has been accepted, > it > should not be revisited by the F/RTF during the current revision > cycle. > > [The prohibition against revisiting a clarification is not intended > to > shackle the F/RTF, but to give clarifications generated by this > process > some stability. The requirements of branding programs are the > primary > motivation for this process. An Urgent Issue that alters a branding > test > suite may affect the implementation of shipping, branded software > products, requiring one or more vendors to alter their products to > conform > to the specification as clarified. It is reasonable for vendors to > expect > that the clarification will not be arbitrarily reversed simply > because the > balance of opinion in an F/RTF shifts for some reason (e.g., a > change in > membership) before its final revision proposal is recommended to the > parent Technology Committee. The need for stability is balanced > against > the need for TC approval. It is possible for the TC to reject the > recommendation of an TF (and thus, a set of clarifications), but our > assumption is that the TC understands the consequences of such a > decision > and would only do so under extraordinary circumstances. > > As an example: If a specification's current revision is numbered > 2.1, > clarifications will be identified separately, such as "clarification > 1 of > revision 2.1", and so on. When an F/RTF produces its revision > recommendation (either explicitly or by default), the clarifications > will > be folded into the overall revision, resulting in revision 2.2. If > the > F/RTF fails to produce a recommendation, OMG staff will collect > clarifications into a revision recommendation. ] > > > -- Jeff Mischkinsky jmischki@dcn.davis.ca.us +1 530-758-9850 jeffm@inprise.com +1 650-358-3049 Content-return: allowed Date: Mon, 15 Mar 1999 08:53:49 -0500 From: "Barker, Thomas" Subject: RE: Issues 2533 & 2534 classified as urgent To: "'Andrew Watson'" , tom_barker@omg.org, c_mapping-rtf@omg.org Cc: issues@omg.org Issues 309, 322 and 323 also relate to this question. Lets plan on covering them all and voting in the changes to 19.8 by 3/24. I'm considering the changes as they are applicable to CORBA v2.2. I don't even know where to find the copy of v2.1. Section 4.3.2 was in the old spec and the v2.2 spec does not have the same number. Does anybody know where that section moved? > -----Original Message----- > From: Andrew Watson [SMTP:andrew@omg.org] > Sent: Friday, March 12, 1999 6:03 PM > To: tom_barker@omg.org; c_mapping-rtf@omg.org > Cc: issues@omg.org > Subject: Issues 2533 & 2534 classified as urgent > > Dear Tom and members of the C mapping RTF, > > As you may have seen, we have been sent a couple of clarification > requests > by The Open Group. We've categorised these as C revision issues and > classified them as urgent, which according to section 4.4.1.5 of the > P&P > means that OMG must respond with a resolution within two weeks. > > I'm appending the relevant section of the P&P to this message, but > broadly > speaking, the procedure for urgent resolutions is: > > 1. Once OMG staff has decided they're urgent issues, they're filed > in the > ordinary way. > > 2. Staff provides a proposed resolution (see below). If the RTF for > some > reason does not come to a decision on resolving the issues, > staff > submit > a resolution, and absent any other contributions, it's likely to > be > this > one. > > 3. You have two weeks to discuss and vote on a resolution in the > normal > way. > > 4. Two weeks from today (Friday 26th March), we will pass back to > the > Open > Group the result of your deliberations (or, in the unlikely > event you > haven't voted on a resolution, a staff proposal). > > Here are the staff proposed resolutions: > > For issue 2533 (TOG Reference: req.1.O.00009), staff proposes that > allocating longs in Anys using CORBA_alloc be considered standard > (solution > 1): > > any->_type = TC_long; > any->_value = CORBA_alloc(sizeof(CORBA_long)); > > For issue 2534 (TOG Reference: req.1.O.00010), staff proposes that > the > definition of send_multiple_requests() in section 4.3.2 be ruled in > error, > and be changed to align with the rules section 17.17. > > If you have any questions on the urgent resolution process, please > get in > touch with me. > Regards, > > Andrew > Andrew Watson Tel: +1 508 820 4300 > x111 > VP Technology Fax: +1 508 820 4303 > Object Management Group, Email: andrew@omg.org > 492 Old Connecticut Path, Lat/Lon: 42.3122 N > 71.3927 W > Framingham, MA 01701, USA > http://www.omg.org/~andrew > > > ----------------------------------------------------------------- > > 4.4.1.5 Urgent Issues > > In response to urgent requests for clarifications to a specification > ("Urgent Issues"), the OMG shall provide clarifications of specific > issues. > > [Issues may arise that require interpretation or clarification of a > specification in a very short period of time. For example, there may > be > disputes over interpretation during the course of conformance > testing in > the context of a branding program, or urgent clarifications required > by a > vendor during product implementation. Resolution needs to occur > within a > very short period of time (approximately 2 weeks), and should result > in > modifications on a point-by-point basis.] > > Urgent Issues shall be directed to the OMG Technical Director (or > his > appointee), who will determine whether the issue is appropriate for > urgent > resolution, and if so direct it to the appropriate F/RTF. If no > appropriate F/RTF is currently active, the Architecture Board will > be > responsible for resolving the issue. The Technical Director (or his > appointee) will propose specific wording for the clarification to > the > committee (either the RTF or AB). The committee is then at liberty > to vote > on the proposed clarification or to propose other > clarifications. The > issue is deemed closed when a particular clarification has been > accepted > by a poll of the F/RTF members. If a period of two weeks has passed > from > the receipt of the issue by the Technical Director and no > clarification > has been accepted, the Technical Director (or his appointee) will > determine an appropriate clarification. > > [A clarification (in the > when there are multiple, incompatible interpretations. In cases > where a > specification is not logically consistent, a clarification may also > render > a part of a specification void or add new content, only inasmuch as > it is > necessary to make the specification consistent. This process must > never be > used to extend a specification's functionality. > > The deployment of the Architecture Board in this role is intended as > a > backstop, a last resort in case an appropriate F/RTF is not > active. The > Architecture Board should by no means become the "normal" vehicle > for > resolving issues of this nature. It is the responsibility and duty > of the > Technology Committees to charter F/RTFs for Adopted and Available > Specifications and maintain their readiness to respond as needed. > > It will most likely be the case that committee discussions and polls > on > urgent issues will be conducted electronically. OMG staff will > maintain > appropriate email and document exchange mechanisms to facilitate > this > process.] > > Resolutions of Urgent Issues will be formulated and maintained as > isolated > revisions to the specification, identified by sequential natural > numbers > and made publicly available. Any clarifications produced by this > process > shall be incorporated into the final recommendation produced by the > F/RTF. > Should there not be an appropriate F/RTF, or if the F/RTF does not > produce > a recommendation before its delivery deadline, any clarifications > produced > in this manner will automatically and collectively constitute a > recommendation of revision. Once a clarification has been accepted, > it > should not be revisited by the F/RTF during the current revision > cycle. > > [The prohibition against revisiting a clarification is not intended > to > shackle the F/RTF, but to give clarifications generated by this > process > some stability. The requirements of branding programs are the > primary > motivation for this process. An Urgent Issue that alters a branding > test > suite may affect the implementation of shipping, branded software > products, requiring one or more vendors to alter their products to > conform > to the specification as clarified. It is reasonable for vendors to > expect > that the clarification will not be arbitrarily reversed simply > because the > balance of opinion in an F/RTF shifts for some reason (e.g., a > change in > membership) before its final revision proposal is recommended to the > parent Technology Committee. The need for stability is balanced > against > the need for TC approval. It is possible for the TC to reject the > recommendation of an TF (and thus, a set of clarifications), but our > assumption is that the TC understands the consequences of such a > decision > and would only do so under extraordinary circumstances. > > As an example: If a specification's current revision is numbered > 2.1, > clarifications will be identified separately, such as "clarification > 1 of > revision 2.1", and so on. When an F/RTF produces its revision > recommendation (either explicitly or by default), the clarifications > will > be folded into the overall revision, resulting in revision 2.2. If > the > F/RTF fails to produce a recommendation, OMG staff will collect > clarifications into a revision recommendation. ] > X-Sender: siegel@192.67.184.65 Date: Mon, 15 Mar 1999 09:47:51 -0500 To: "Barker, Thomas" From: Jon Siegel Subject: RE: Issues 2533 & 2534 classified as urgent Cc: "'Andrew Watson'" , tom_barker@omg.org, c_mapping-rtf@omg.org, issues@omg.org Hi, all -- The old specs are archived in the "formal" subdirectory of the document directory. To get at everything, go to http://www.omg.org/cgi-bin/members/doclistm.pl log in, and select "formal" in the "select subgroups" box and search for "2.1". You'll find ... The docs you want are availble as either formal/97-11-04: CORBA 2.1 with change bars (Contact: Mr. Juergen Boldt) No description of this document is available. Formats: Gzipped PostScript, PostScript, PDF formal/97-11-03: CORBA 2.1 without change bars (Contact: Mr. Juergen Boldt) No description of this document is available. Formats: Gzipped PostScript, PostScript, PDF Enjoy -- Jon Siegel OMG At 08:53 AM 3/15/99 -0500, Barker, Thomas wrote: >Issues 309, 322 and 323 also relate to this question. Lets plan on covering >them all and voting in the changes to 19.8 by 3/24. > >I'm considering the changes as they are applicable to CORBA v2.2. I don't >even know where to find the copy of v2.1. Section 4.3.2 was in the old spec >and the v2.2 spec does not have the same number. Does anybody know where >that section moved? > >> -----Original Message----- >> From: Andrew Watson [SMTP:andrew@omg.org] >> Sent: Friday, March 12, 1999 6:03 PM >> To: tom_barker@omg.org; c_mapping-rtf@omg.org >> Cc: issues@omg.org >> Subject: Issues 2533 & 2534 classified as urgent >> >> Dear Tom and members of the C mapping RTF, >> >> As you may have seen, we have been sent a couple of clarification requests >> by The Open Group. We've categorised these as C revision issues and >> classified them as urgent, which according to section 4.4.1.5 of the P&P >> means that OMG must respond with a resolution within two weeks. >> >> I'm appending the relevant section of the P&P to this message, but broadly >> speaking, the procedure for urgent resolutions is: >> >> 1. Once OMG staff has decided they're urgent issues, they're filed in the >> ordinary way. >> >> 2. Staff provides a proposed resolution (see below). If the RTF for some >> reason does not come to a decision on resolving the issues, staff >> submit >> a resolution, and absent any other contributions, it's likely to be >> this >> one. >> >> 3. You have two weeks to discuss and vote on a resolution in the normal >> way. >> >> 4. Two weeks from today (Friday 26th March), we will pass back to the >> Open >> Group the result of your deliberations (or, in the unlikely event you >> haven't voted on a resolution, a staff proposal). >> >> Here are the staff proposed resolutions: >> >> For issue 2533 (TOG Reference: req.1.O.00009), staff proposes that >> allocating longs in Anys using CORBA_alloc be considered standard >> (solution >> 1): >> >> any->_type = TC_long; >> any->_value = CORBA_alloc(sizeof(CORBA_long)); >> >> For issue 2534 (TOG Reference: req.1.O.00010), staff proposes that the >> definition of send_multiple_requests() in section 4.3.2 be ruled in error, >> and be changed to align with the rules section 17.17. >> >> If you have any questions on the urgent resolution process, please get in >> touch with me. >> Regards, >> >> Andrew >> Andrew Watson Tel: +1 508 820 4300 x111 >> VP Technology Fax: +1 508 820 4303 >> Object Management Group, Email: andrew@omg.org >> 492 Old Connecticut Path, Lat/Lon: 42.3122 N 71.3927 W >> Framingham, MA 01701, USA http://www.omg.org/~andrew >> >> ----------------------------------------------------------------- >> >> 4.4.1.5 Urgent Issues >> >> In response to urgent requests for clarifications to a specification >> ("Urgent Issues"), the OMG shall provide clarifications of specific >> issues. >> >> [Issues may arise that require interpretation or clarification of a >> specification in a very short period of time. For example, there may be >> disputes over interpretation during the course of conformance testing in >> the context of a branding program, or urgent clarifications required by a >> vendor during product implementation. Resolution needs to occur within a >> very short period of time (approximately 2 weeks), and should result in >> modifications on a point-by-point basis.] >> >> Urgent Issues shall be directed to the OMG Technical Director (or his >> appointee), who will determine whether the issue is appropriate for urgent >> resolution, and if so direct it to the appropriate F/RTF. If no >> appropriate F/RTF is currently active, the Architecture Board will be >> responsible for resolving the issue. The Technical Director (or his >> appointee) will propose specific wording for the clarification to the >> committee (either the RTF or AB). The committee is then at liberty to vote >> on the proposed clarification or to propose other clarifications. The >> issue is deemed closed when a particular clarification has been accepted >> by a poll of the F/RTF members. If a period of two weeks has passed from >> the receipt of the issue by the Technical Director and no clarification >> has been accepted, the Technical Director (or his appointee) will >> determine an appropriate clarification. >> >> [A clarification (in the sense used here) typically eliminates an >> ambiguity by narrowing the possible interpretations of a specification >> when there are multiple, incompatible interpretations. In cases where a >> specification is not logically consistent, a clarification may also render >> a part of a specification void or add new content, only inasmuch as it is >> necessary to make the specification consistent. This process must never be >> used to extend a specification's functionality. >> >> The deployment of the Architecture Board in this role is intended as a >> backstop, a last resort in case an appropriate F/RTF is not active. The >> Architecture Board should by no means become the "normal" vehicle for >> resolving issues of this nature. It is the responsibility and duty of the >> Technology Committees to charter F/RTFs for Adopted and Available >> Specifications and maintain their readiness to respond as needed. >> >> It will most likely be the case that committee discussions and polls on >> urgent issues will be conducted electronically. OMG staff will maintain >> appropriate email and document exchange mechanisms to facilitate this >> process.] >> >> Resolutions of Urgent Issues will be formulated and maintained as isolated >> revisions to the specification, identified by sequential natural numbers >> and made publicly available. Any clarifications produced by this process >> shall be incorporated into the final recommendation produced by the F/RTF. >> Should there not be an appropriate F/RTF, or if the F/RTF does not produce >> a recommendation before its delivery deadline, any clarifications produced >> in this manner will automatically and collectively constitute a >> recommendation of revision. Once a clarification has been accepted, it >> should not be revisited by the F/RTF during the current revision cycle. >> >> [The prohibition against revisiting a clarification is not intended to >> shackle the F/RTF, but to give clarifications generated by this process >> some stability. The requirements of branding programs are the primary >> motivation for this process. An Urgent Issue that alters a branding test >> suite may affect the implementation of shipping, branded software >> products, requiring one or more vendors to alter their products to conform >> to the specification as clarified. It is reasonable for vendors to expect >> that the clarification will not be arbitrarily reversed simply because the >> balance of opinion in an F/RTF shifts for some reason (e.g., a change in >> membership) before its final revision proposal is recommended to the >> parent Technology Committee. The need for stability is balanced against >> the need for TC approval. It is possible for the TC to reject the >> recommendation of an TF (and thus, a set of clarifications), but our >> assumption is that the TC understands the consequences of such a decision >> and would only do so under extraordinary circumstances. >> >> As an example: If a specification's current revision is numbered 2.1, >> clarifications will be identified separately, such as "clarification 1 of >> revision 2.1", and so on. When an F/RTF produces its revision >> recommendation (either explicitly or by default), the clarifications will >> be folded into the overall revision, resulting in revision 2.2. If the >> F/RTF fails to produce a recommendation, OMG staff will collect >> clarifications into a revision recommendation. ] >> > > ================================================================== Jon Siegel Phone: 508-820-4300 X124 Director, Domain Technology Fax: 508-820-4303 Object Management Group 492 Old Connecticut Path email: siegel@omg.org Framingham, Massachusetts 01701 USA http://www.omg.org ================================================================== X-Sender: andrew@emerald.omg.org Date: Mon, 15 Mar 1999 11:06:23 -0500 To: "Barker, Thomas" From: Andrew Watson Subject: RE: Issues 2533 & 2534 classified as urgent Cc: tom_barker@omg.org, c_mapping-rtf@omg.org, issues@omg.org, Linda Heaton Tom, You wrote: > Issues 309, 322 and 323 also relate to this question. Lets plan on > covering them all and voting in the changes to 19.8 by 3/24. I'm glad to see that this isn't the first time this has been noticed! > I'm considering the changes as they are applicable to CORBA v2.2. I don't > even know where to find the copy of v2.1. Section 4.3.2 was in the old > spec and the v2.2 spec does not have the same number. Does anybody know > where that section moved? You can get hold of copies of the 2.1 specification from these URLs: http://www.omg.org/cgi-bin/doc?formal/97-11-04 CORBA 2.1 with change bars http://www.omg.org/cgi-bin/doc?formal/97-11-03 CORBA 2.1 (no change bars) While you're looking at this, I'd recommend checking whether this problem was propogated to 2.2 and to the forthcoming 2.3 spec. [Linda - please can you work with Tom to check whether these problems with the C mapping chapter in 2.1 are still there in 2.3? Thanks.] Cheers, Andrew X-Sender: andrew@emerald.omg.org References: from "Andrew Watson" at Mar 12, 99 06:03:03 pm Date: Mon, 15 Mar 1999 10:55:48 -0500 To: Jeffrey Mischkinsky From: Andrew Watson Subject: Re: Issues 2533 & 2534 classified as urgent Cc: tom_barker@omg.org, c_mapping-rtf@omg.org, issues@omg.org Jeff, You wrote: > It might be helpful in the future if "omg staff", which I suppose is the > long-suffering and over-worked person currently manifested as yourself, > provided a bit of the rationale for his or her recommendations. So you want to know what denomination of coin I tossed to decide? :-) But seriously ... I think perhaps "recommendation" is probably the wrong word for this - "threat" or "fair warning" might be closer to the mark. In the unlikely event that we have a delinquent or deadlocked RTF which fails to make a decision within the two weeks, the Technical Director steps into the breach and sends back a resolution - by including a proposed resolution in the notification, I'm giving the RTF fair warning of what will (probably) be the OMG reply if they don't respond. Of course, this means that if I want to make sure the RTF takes the decision (and I do!), then I should probably pick the least-useful, most-disruptive interpretation as the default, so that the RTF has an incentive to override it :-). AFAIK I haven't this time, but you have been warned! > I personally agree with your suggestion on #1, and will probably agree > with #2, but i have to do my due diligence and go look at the referenced > sections first. I would expect no less! Cheers, Andrew Sender: jis@fpk.hp.com Date: Mon, 15 Mar 1999 12:07:38 -0500 From: Jishnu Mukerji Organization: Hewlett-Packard EIAL To: Andrew Watson CC: tom_barker@omg.org, c_mapping-rtf@omg.org, issues@omg.org Subject: Re: Issues 2533 & 2534 classified as urgent References: > Here are the staff proposed resolutions: > > For issue 2533 (TOG Reference: req.1.O.00009), staff proposes that > allocating longs in Anys using CORBA_alloc be considered standard > (solution > 1): > > any->_type = TC_long; > any->_value = CORBA_alloc(sizeof(CORBA_long)); I agree with the staff position on this one. > For issue 2534 (TOG Reference: req.1.O.00010), staff proposes that the > definition of send_multiple_requests() in section 4.3.2 be ruled in error, > and be changed to align with the rules section 17.17. First of all what used to be section 4.3.2 is now section 7.3.2. and what used to be 17.17 is now somewhere in the 20's probably.:-) 1. The envp parameter belongs in the end of the parameter list. This was fixed in the DII chapter in Core RTF 2.3. 2. Actually, one could argue that VSOrb is wrong in assuming that send_multiple_requests is an ORB operation. Apparently they assume this since they place the ORB as the first argument. It never has been part of the ORB interface in chapter 4. Certain language mappings have placed it in the ORB class (e.g. C++), and this may very well be the time to change the C mapping so as to make it look like it is part of the ORB interface. But in the originally adopted CORBA, for reasons that are not very clear to me, the two functions send_multiple_requests and get_next_response were deliberately not made part of the ORB interface. Maybe our C ORB expert Dan Frantz can shed some light on this matter. So, on point 2 I have a problem blessing an interpretation that is clearly a signifcant (and not very necessary) change in 2.1, which may have consequences in other language mappings like COBOL and Smalltalk, and in deployed C ORBs. Of course if all deployed C ORBs are OK with this then that makes the case stronger for accepting this as the way to go in the conformance testing tool, and to fix the spec.:-) So until I hear some more rationale I am going to vote a partial NO on the staff recommendation on issue 2534. Partial, because envp should be the last paramter (The partial YES) and there should be no orb argument (the NO part). So what say you Oh Gurus of ORB-dome? Jishnu. -- Jishnu Mukerji Systems Architect Email: jis@fpk.hp.com Hewlett-Packard EIAL, Tel: +1 973 443 7528 300 Campus Drive, 2E-62, Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Content-return: allowed Date: Mon, 15 Mar 1999 14:50:42 -0500 From: "Barker, Thomas" Subject: RE: Issues 2533 & 2534 classified as urgent To: "'Jishnu Mukerji'" , Andrew Watson Cc: tom_barker@omg.org, c_mapping-rtf@omg.org, issues@omg.org Issue staff solution to 2533 seems agreeable to all. It would take a new paragraph in the v2.2 Section 19.8. I'll draft one and send it out for comment this evening or Wed (unless someone else wants to do it. I have to travel tomorrow.) On 2534 I sort of agree with staff that the v2.1 Section 4.3.2 (it became v2.2 Section 5.3.2) is wrong but I don't see the same error that Jishnu sees. Why should the send_multiple_requests operation be defined by giving a C and Smalltalk example. If it was defined using PIDL then normal language mapping chapters would handle the subtleties of each language. The question of whether it belongs to the ORB or not seems independent. > -----Original Message----- > From: Jishnu Mukerji [SMTP:jis@fpk.hp.com] > Sent: Monday, March 15, 1999 12:08 PM > To: Andrew Watson > Cc: tom_barker@omg.org; c_mapping-rtf@omg.org; issues@omg.org > Subject: Re: Issues 2533 & 2534 classified as urgent > > > Here are the staff proposed resolutions: > > > > For issue 2533 (TOG Reference: req.1.O.00009), staff proposes that > > allocating longs in Anys using CORBA_alloc be considered standard > (solution > > 1): > > > > any->_type = TC_long; > > any->_value = CORBA_alloc(sizeof(CORBA_long)); > > I agree with the staff position on this one. > > > For issue 2534 (TOG Reference: req.1.O.00010), staff proposes that > the > > definition of send_multiple_requests() in section 4.3.2 be ruled > in > error, > > and be changed to align with the rules section 17.17. > > First of all what used to be section 4.3.2 is now section 7.3.2. and > what used to be 17.17 is now somewhere in the 20's probably.:-) > > 1. The envp parameter belongs in the end of the parameter list. This > was > fixed in the DII chapter in Core RTF 2.3. > > 2. Actually, one could argue that VSOrb is wrong in assuming that > send_multiple_requests is an ORB operation. Apparently they assume > this > since they place the ORB as the first argument. It never has been > part > of the ORB interface in chapter 4. Certain language mappings have > placed > it in the ORB class (e.g. C++), and this may very well be the time > to > change the C mapping so as to make it look like it is part of the > ORB > interface. But in the originally adopted CORBA, for reasons that are > not > very clear to me, the two functions send_multiple_requests and > get_next_response were deliberately not made part of the ORB > interface. > Maybe our C ORB expert Dan Frantz can shed some light on this > matter. > > So, on point 2 I have a problem blessing an interpretation that is > clearly a signifcant (and not very necessary) change in 2.1, which > may > have consequences in other language mappings like COBOL and > Smalltalk, > and in deployed C ORBs. Of course if all deployed C ORBs are OK with > this then that makes the case stronger for accepting this as the way > to > go in the conformance testing tool, and to fix the spec.:-) > > So until I hear some more rationale I am going to vote a partial NO > on > the staff recommendation on issue 2534. Partial, because envp should > be > the last paramter (The partial YES) and there should be no orb > argument > (the NO part). > > So what say you Oh Gurus of ORB-dome? > > Jishnu. > > -- > Jishnu Mukerji > Systems Architect > > Email: jis@fpk.hp.com Hewlett-Packard EIAL, > Tel: +1 973 443 7528 300 Campus Drive, 2E-62, > Fax: +1 973 443 7422 Florham Park, NJ 07932, USA. Content-return: allowed Date: Mon, 15 Mar 1999 17:28:21 -0500 From: "Barker, Thomas" Subject: RE: issue 2533 C Language mapping RTF Issue To: "'Juergen Boldt'" , issues@emerald.omg.org, c_mapping-rtf@emerald.omg.org, c-rev-wg@emerald.omg.org In the last note I indicated we could agree that solution 1 was ok, but when I started to draft a clarifying paragraph (and talked to our developers) it seemed that solution 2 was called for by the existing spec and further it better satisfied the intent of the spec. Both solutions are providing _alloc operations so both are generating heap allocations and they are therefore covered by the existing paragraph. Further each should therefore use CORBA_free. Since CORBA_free does not take a parameter indicating the type, use of the T_alloc() operation permits the implementation to hide type flags. Using the CORBA_alloc(sizeof(T)) method would require the CORBA_alloc, CORBA_free to coordinate by using for example: the address of the allocated space or by hiding a type field in the allocation. Since adding T_alloc'ers was easy while handling the hidden length fields that are inconsistent with the constructed type fields would be awkward we came to the conclusion that solution 2 was better. At this point I would vote for solution 2 and simply clarify the spec by adding the example provided by the issue immediately following the line: T *T__alloc( ); /* C */ "To initialize the fields of an any for a CORBA basic type being allocated to the heap, the following C code might be utilized: any->type = TC_T any_>value = T__alloc( ); If the CORBA basic type value for the any was not allocated from the heap then the type specific allocator would not be used." Tom > -----Original Message----- > From: Juergen Boldt [SMTP:juergen@omg.org] > Sent: Friday, March 12, 1999 4:37 PM > To: issues@emerald.omg.org; c_mapping-rtf@emerald.omg.org; > c-rev-wg@emerald.omg.org > Subject: issue2533 C Language mapping RTF Issue > Importance: High > > This is issue # 2533 > > How to allocate storage for a basic type you wish to place in an > any? > > Under the C mapping how do you allocate storage for a basic type > you wish to place in an any. > > Consider inserting a long into an Any. > > Do you do this: solution 1 > > any->_type = TC_long; > any->_value = CORBA_alloc(sizeof(CORBA_long)); > > or this: solution 2 > > any->_type = TC_long; > any->_value = CORBA_long__alloc(); > > One vendor argues that the text below supports solution > 2. However > as a long is not a constructed type solution 1 seems more > natural. > > >From "17.8 Mapping Considerations for Constructed Types" of > CORBA > 2.1 > specification: > > "For types whose parameter passing modes require heap > allocation, > an ORB implementation will provide allocation functions. These > types > include variable-length struct, variable-length union, > sequence, any, > string, wstring and array of a variable-length type. The return > value > of these allocation functions must be freed using > CORBA_free(). For > one of these listed types T, the ORB implementation will > provide > the following type-specific allocation function: > > T *T__alloc(); /* C */" > > > ================================================================ > > Juergen Boldt > Senior Member of Technical Staff > > Object Management Group Tel. +1-508-820 4300 ext. 132 > Framingham Corporate Center Fax: +1-508-820 4303 > 492 Old Connecticut Path Email: juergen@omg.org > Framingham, MA 01701 > > ================================================================ Content-return: allowed Date: Mon, 15 Mar 1999 17:28:21 -0500 From: "Barker, Thomas" Subject: RE: issue 2533 C Language mapping RTF Issue To: "'Juergen Boldt'" , issues@emerald.omg.org, c_mapping-rtf@emerald.omg.org, c-rev-wg@emerald.omg.org In the last note I indicated we could agree that solution 1 was ok, but when I started to draft a clarifying paragraph (and talked to our developers) it seemed that solution 2 was called for by the existing spec and further it better satisfied the intent of the spec. Both solutions are providing _alloc operations so both are generating heap allocations and they are therefore covered by the existing paragraph. Further each should therefore use CORBA_free. Since CORBA_free does not take a parameter indicating the type, use of the T_alloc() operation permits the implementation to hide type flags. Using the CORBA_alloc(sizeof(T)) method would require the CORBA_alloc, CORBA_free to coordinate by using for example: the address of the allocated space or by hiding a type field in the allocation. Since adding T_alloc'ers was easy while handling the hidden length fields that are inconsistent with the constructed type fields would be awkward we came to the conclusion that solution 2 was better. At this point I would vote for solution 2 and simply clarify the spec by adding the example provided by the issue immediately following the line: T *T__alloc( ); /* C */ "To initialize the fields of an any for a CORBA basic type being allocated to the heap, the following C code might be utilized: any->type = TC_T any_>value = T__alloc( ); If the CORBA basic type value for the any was not allocated from the heap then the type specific allocator would not be used." Tom > -----Original Message----- > From: Juergen Boldt [SMTP:juergen@omg.org] > Sent: Friday, March 12, 1999 4:37 PM > To: issues@emerald.omg.org; c_mapping-rtf@emerald.omg.org; > c-rev-wg@emerald.omg.org > Subject: issue2533 C Language mapping RTF Issue > Importance: High > > This is issue # 2533 > > How to allocate storage for a basic type you wish to place in an > any? > > Under the C mapping how do you allocate storage for a basic type > you wish to place in an any. > > Consider inserting a long into an Any. > > Do you do this: solution 1 > > any->_type = TC_long; > any->_value = CORBA_alloc(sizeof(CORBA_long)); > > or this: solution 2 > > any->_type = TC_long; > any->_value = CORBA_long__alloc(); > > One vendor argues that the text below supports solution > 2. However > as a long is not a constructed type solution 1 seems more > natural. > > >From "17.8 Mapping Considerations for Constructed Types" of > CORBA > 2.1 > specification: > > "For types whose parameter passing modes require heap > allocation, > an ORB implementation will provide allocation functions. These > types > include variable-length struct, variable-length union, > sequence, any, > string, wstring and array of a variable-length type. The return > value > of these allocation functions must be freed using > CORBA_free(). For > one of these listed types T, the ORB implementation will > provide > the following type-specific allocation function: > > T *T__alloc(); /* C */" > > > ================================================================ > > Juergen Boldt > Senior Member of Technical Staff > > Object Management Group Tel. +1-508-820 4300 ext. 132 > Framingham Corporate Center Fax: +1-508-820 4303 > 492 Old Connecticut Path Email: juergen@omg.org > Framingham, MA 01701 > > ================================================================ X-My-Real-Login-Name: sugino; 10.35.109.43 Date: Tue, 16 Mar 1999 19:03:28 +0900 From: Yasuaki Sugino To: "Barker, Thomas" , "'Juergen Boldt'" , issues@emerald.omg.org, c_mapping-rtf@emerald.omg.org, c-rev-wg@emerald.omg.org References: <99AA2270B1E6D111BCE10000F805F17F01395D2D@emss35m02.owg.fs.lmco.com> Subject: Re^2: issue 2533 C Language mapping RTF Issue Hi members, My name is Yasuaki Sugino and I'm a member of C mapping RTF. I would like to say on 2533. "Barker, Thomas" , "'Juergen Boldt'" , issues@emerald.omg.org, c_mapping-rtf@emerald.omg.org, c-rev-wg@emerald.omg.org wrote Mon, 15 Mar 1999 17:28:21 -0500 Subject: "RE: issue 2533 C Language mapping RTF Issue" "Barker,> In the last note I indicated we could agree that solution 1 was ok, but when "Barker,> I started to draft a clarifying paragraph (and talked to our developers) it "Barker,> seemed that solution 2 was called for by the existing spec and further it "Barker,> better satisfied the intent of the spec. Both solutions are providing "Barker,> _alloc operations so both are generating heap allocations and they are "Barker,> therefore covered by the existing paragraph. Further each should therefore "Barker,> use CORBA_free. Since CORBA_free does not take a parameter indicating the "Barker,> type, use of the T_alloc() operation permits the implementation to hide type "Barker,> flags. Using the CORBA_alloc(sizeof(T)) method would require the "Barker,> CORBA_alloc, CORBA_free to coordinate by using for example: the address of "Barker,> the allocated space or by hiding a type field in the allocation. Since "Barker,> adding T_alloc'ers was easy while handling the hidden length fields that are "Barker,> inconsistent with the constructed type fields would be awkward we came to "Barker,> the conclusion that solution 2 was better. I agree with you. I discussed with our CORBA ORB developers and we concluded that solution 2 was better. I would like to vote for solution 2. But I have one more quesion in "17.8 Mapping Considerations for Constructed Types". ------------------------------------ T *T__alloc(); /* C */ ------------------------------------- In above, the declaration has two underbars between "any" and "alloc". But CORBA_any_alloc() has one underbar between them. What does it mean ? I believe that T means *only* "user defined type" and alloc functions for build-in types(long, any, etc) has one underbar between them as below. ---------------------------------------------------------- CORBA_any *CORBA_any_alloc(); char *CORBA_string_alloc(); CORBA_wchar* CORBA_wstring_alloc(CORBA_unsigned_long len); ----------------------------------------------------------- So, I think the following added explanation is not enough to resolve issue #2533. "Barker,> At this point I would vote for solution 2 and simply clarify the spec by "Barker,> adding the example provided by the issue immediately following the line: "Barker,> "Barker,> T *T__alloc( ); /* C */ "Barker,> "Barker,> "To initialize the fields of an any for a CORBA basic type being allocated "Barker,> to the heap, the following C code might be utilized: "Barker,> any->type = TC_T "Barker,> any_>value = T__alloc( ); "Barker,> If the CORBA basic type value for the any was not allocated from the heap "Barker,> then the type specific allocator would not be used." "Barker,> ----- Best Regards Yasuaki SUGINO FUJITSU LIMITED From: "Stephen Mc Namara" To: "Barker, Thomas" , , , Subject: Re: issue 2533 C Language mapping RTF Issue Date: Tue, 16 Mar 1999 13:11:03 -0000 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Hi all, As the developers of VSOrb we took the view that solution 1 was correct and that untyped allocation was the best solution. If option 2 is now gathering support an important consequence needs to be considered at the same time. Our reading of the spec, (which agrees with at least one ORB vendor we have come across) is that in a CORBA_any the value member points to an instance of the type. e.g. for CORBA_long value points to an instance of a CORBA_long The problem is what to do with strings. Strings are mapped to CORBA_char *. So when placing a string in a CORBA_any, the value member points to an instance of CORBA_char* (which in turn points to the actual characters in the string). If CORBA_long__alloc() is to be used to allocate storage for a long what is used for CORBA_Char* ? CORBA_string__alloc() would be very easily confused with CORBA_string_alloc(). The first function allocates the space for the value holder, the second the space for the string itself. As they differ by a single underscore there is potential for further confusion and ambiguity. stephen >In the last note I indicated we could agree that solution 1 was ok, but when >I started to draft a clarifying paragraph (and talked to our developers) it >seemed that solution 2 was called for by the existing spec and further it >better satisfied the intent of the spec. Both solutions are providing >_alloc operations so both are generating heap allocations and they are >therefore covered by the existing paragraph. Further each should therefore >use CORBA_free. Since CORBA_free does not take a parameter indicating the >type, use of the T_alloc() operation permits the implementation to hide type >flags. Using the CORBA_alloc(sizeof(T)) method would require the >CORBA_alloc, CORBA_free to coordinate by using for example: the address of >the allocated space or by hiding a type field in the allocation. Since >adding T_alloc'ers was easy while handling the hidden length fields that are >inconsistent with the constructed type fields would be awkward we came to >the conclusion that solution 2 was better. X-My-Real-Login-Name: sugino; 10.35.109.43 Date: Wed, 17 Mar 1999 19:42:54 +0900 From: Yasuaki Sugino To: "Stephen Mc Namara" , "Barker, Thomas" , , , References: <08f901be6fae$aae6aef0$e9787dc2@black.aptest.ie> Subject: Re^2: issue 2533 C Language mapping RTF Issue "Stephen Mc Namara" , "Barker, Thomas" , , , wrote Tue, 16 Mar 1999 13:11:03 -0000 Subject: "Re: issue 2533 C Language mapping RTF Issue" "Stephen> Our reading of the spec, (which agrees with at least one ORB vendor we have "Stephen> come across) is that in a CORBA_any the value member points to an instance "Stephen> of the type. e.g. for CORBA_long value points to an instance of a CORBA_long Yes. I agree with you on above part. "Stephen> The problem is what to do with strings. "Stephen> "Stephen> Strings are mapped to CORBA_char *. So when placing a string in a CORBA_any, "Stephen> the value member points to an instance of CORBA_char* (which in turn points "Stephen> to the actual characters in the string). I don't understand why you think so ... I believe that a string is not mapped to CORBA_char*, but a string is just expressed by CORBA_char*. Actually, "17.12 Mapping for Strings" of CORBA 2.1 specification states: "OMG IDL strings are mapped to 0-byte terminated characer arrays." So the value member should point to an instance of a string. "Stephen> "Stephen> If CORBA_long__alloc() is to be used to allocate storage for a long what is "Stephen> used for CORBA_Char* ? "Stephen> "Stephen> CORBA_string__alloc() would be very easily confused with "Stephen> CORBA_string_alloc(). "Stephen> "Stephen> The first function allocates the space for the value holder, the second the "Stephen> space for the string itself. As they differ by a single underscore there is "Stephen> potential for further confusion and ambiguity. According to "17.21 Summary of Argument/Result Passing", the value holders are expressed by pointers. So I think the first function is useless in C language mapping. I believe you can use only the second to allocate the space for the string. ----- Best Regards Yasuaki SUGINO FUJITSU LIMITED X-Sender: andrew@emerald.omg.org Date: Fri, 26 Mar 1999 00:29:20 -0500 To: Jenny Wilkinson From: Andrew Watson Subject: Re: OMG review of req.1.O.00009 (OMG issue 2533) Cc: ogomgorb@opengroup.org, issues@omg.org, c_mapping-rtf@omg.org Jenny, You wrote: > INTERPRETATION REQUEST DOCUMENT TOG Reference: req.1.O.00009 Here is the OMG reply to your interpretation request: > Component: CORBA > > Section B - Interpretation Request Details > > Version/Release: VSORB 1.1.0 > > Testset: iiop//all Test No: 0 > > Waiver Reason: Grey area in the Specification > > Test Results: > not available > > Additional Commentary: > The issue is: > > Under the C mapping how do you allocate storage for a basic type > you wish to place in an any. > > Consider inserting a long into an Any. > > Do you do this: solution 1 > > any->_type = TC_long; > any->_value = CORBA_alloc(sizeof(CORBA_long)); > > or this: solution 2 > > any->_type = TC_long; > any->_value = CORBA_long__alloc(); OMG has selected solution 2. Additional information: In a future CORBA version the the text in section 19.8 of CORBA 2.2 (section 17.8 of CORBA 2.1) will be changed to better illustrate the existing words. The following existing paragraph seems to cover the question, if the type for an any is being allocated to the heap. For types whose parameter passing modes require heap allocation,an ORB implementation will provide allocation functions. These types include variable-length struct, variable-length union, sequence, any, string, wstring and array of a variable-length type. The return value of these allocation functions must be freed using CORBA_free(). For one of these listed types T, the ORB implementation will provide the following type-specific allocation function: T *T__alloc(); /* C */" To clarify the paragraph for type any value we will add the following text. To initialize the fields of an any with type T where T is a CORBA basic type, a T_alloc() operation shall be utilized. For example, an any containing a CORBA_long that was allocated to the heap would be initialized by: any->type = TC_long any_>value = CORBA_long__alloc( ); If the CORBA basic type value for the any was not allocated from the heap then the type specific allocator would not be used. Regards, Andrew Andrew Watson Tel: +1 508 820 4300 x111 VP Technology Fax: +1 508 820 4303 Object Management Group, Email: andrew@omg.org 492 Old Connecticut Path, Lat/Lon: 42.3122 N 71.3927 W Framingham, MA 01701, USA http://www.omg.org/~andrew