Issue 106: Unions represented with either union or struct (c_mapping-rtf) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: In section 14-10 of the C mapping, it says that an ORB can use a struct to hold a union. Doesn"t this cause portability problems? Resolution: Close with no change Revised Text: Actions taken: September 11, 1996: Received issue December 12, 1996: moved from cxx_revision to c-rev-wg October 5, 2000: closed issue Discussion: The spec has to allow that implementations can use something other than a C union because it's not possible to store everything in a C union. Because the spec requires that 'the union type' variable names and techniques be supported it does not cause portability problems when an application is moved from one to another implementation. Since the internal format does not effect the format during transfer there is no interoperability impact. End of Annotations:===== From geoff Wed Sep 11 13:28:28 1996 Received: by amethyst.omg.org.omg.org (5.4R2.01/1.34) id AA05314; Wed, 11 Sep 1996 13:28:28 -0400 Date: Wed, 11 Sep 1996 13:28:28 -0400 From: geoff (Geoffrey Speare) Message-Id: <9609111728.AA05314@amethyst.omg.org.omg.org> To: issue-logger@omg.org Subject: C mapping: unions represented with either union or struct causes portability problems for class libraries X-Omg-Issue: 106 Date: Mon, 9 Sep 1996 17:11:13 PDT Sender: Bill Janssen From: Bill Janssen To: issues@omg.org Subject: C mapping: unions represented with either union or struct causes portability problems for class libraries Cc: orbos@omg.org, bomsig@omg.org A somewhat esoteric problem: In section 14-10, we find ``An ORB implementation need not use a C union to hold the OMG IDL union element; a C struct may be used instead.'' Doesn't this cause binary compatibility problems, thereby rendering C-based class libraries using OMG CORBA technology infeasible,and ceding that whole business sector to Microsoft's COM? Bill >From mail Tue Oct 8 22:44 EDT 1996 Sender: Bill Janssen From: Bill Janssen To: c-rev-wg@omg.org Subject: suggested resolution for issue 106 (unions represented with either union or struct causes portability problems for class libraries) Date: Tue, 8 Oct 1996 19:40:47 PDT Content-Length: 106 I suggest we change the mapping to say that IDL unions must be represented in C with C union types. Bill >From mail Tue Oct 8 22:44 EDT 1996 Sender: Bill Janssen From: Bill Janssen To: c-rev-wg@omg.org Subject: suggested resolution for issue 106 (unions represented with either union or struct causes portability problems for class libraries) Date: Tue, 8 Oct 1996 19:40:47 PDT Content-Length: 106 I suggest we change the mapping to say that IDL unions must be represented in C with C union types. Bill >From mail Thu Oct 31 13:17 EST 1996 Date: 31 Oct 96 09:58:59 -0800 From: "KCOLEMAN.US.ORACLE.COM" To: c-rev-wg@omg.org Subject: Comments on current C issues Content-Length: 4445 Some comments on the issues Bill has posted on his Web page: Issue 106 - Unions as structs or unions --------- While I have no serious problem with Bill's suggested resolution that IDL unions must be implemented as C unions, I don't believe you can assume the kind of binary compatibility suggested by this issue anyway. If you have a library of stubs, you'd better be using headers and/or stubs generated by the same ORB implementation. There is no binary compatibility among objects. Nor can you assume there is any among things like exceptions and the proposed solution to the sequence/any release problem: These structures will all have implementation dependent attributes. Admittedly, they're in the opaque portions of the data structures, but you still can assume binary compatibility with some other implementation. Before tightening this requirement, we should find out whether or not we're going to introduce backward compatibility problems. While this clearly wasn't a concern when the 2.0 mapping was done, it should have been. Date: Mon, 13 Mar 2000 18:11:24 -0500 From: "Barker, Thomas" Subject: Issues to be discused and voted by 3/24/2000(COB) To: "'C-RFT'" Message-id: <99AA2270B1E6D111BCE10000F805F17F043EB1FD@emss35m02.owg.fs.lmco.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-transfer-encoding: 7BIT Content-Type: text/plain; charset=iso-8859-1 X-UIDL: K,Ie9SN0!!?]7!!*@,!! I want to start making some progress on the C RTF (I aplologize for not getting to it earlier, but it been a bad fall and winter). I think that many of the issues can be dealt with quickly so I propose to try to kill about 10 per week for the next couple of months. This batch seemed typical. I just took the first 10 from the list at http://www.omg.org/issues/c_mapping-rtf.html. I'd think the requirement for a vote by 3/24 seems reasonable, but if I discusion between now and 3/17 indicates that any particular issue(s) are not agreeable to everyone I will pull that issue(s) from the list to be voted in this batch. I have gone through the issues, copied the name and summary sentence into this note, then proposed a resolution for each. Tom Issue 106: Unions represented with either union or struct Summary: In section 14-10 of the C mapping, it says that an ORB can use a struct to hold a union. Doesn't this cause portability problems? Discussion - The spec has to allow that implementations can use something other than a C union because it's not possible to store everything in a C union. Because the spec requires that 'the union type' variable names and techniques be supported it does not cause portability problems when an application is moved from one to another implementation. Since the internal format does not effect the format during transfer there is no interoperability impact. In summary I see no impact and it's a required methodology. I suggest it be closed with no change.