Issue 108: Confusing sequence example (c_mapping-rtf) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: The fact that a sequence of longs is to be mapped into a struct is very confusing. 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: There does not seem to be any alternative approach. Since C does not have a sequence primitive the implied parameters, i.e. max length, current length and pointer to data, must be put some where and a struct seems like the obvious answer. Fix typo The IDL code Typedef CORBA_long FRED; Typedef sequence <FRED,10> FredSeq; is commented to be C code. Change /* C */ to be // IDL End of Annotations:===== From geoff Wed Sep 11 13:32:13 1996 Received: by amethyst.omg.org.omg.org (5.4R2.01/1.34) id AA05422; Wed, 11 Sep 1996 13:32:13 -0400 Date: Wed, 11 Sep 1996 13:32:13 -0400 From: geoff (Geoffrey Speare) Message-Id: <9609111732.AA05422@amethyst.omg.org.omg.org> To: issue-logger@omg.org Subject: C mapping: confusing sequence example X-Omg-Issue: 108 Date: Mon, 9 Sep 1996 17:18:56 PDT Sender: Bill Janssen From: Bill Janssen To: issues@omg.org Subject: C mapping: confusing sequence example Cc: orbos@omg.org In section 14-11, the sequence example typedef CORBA_long FRED; /* C */ typedef sequence FredSeq; is defined to be ``mapped onto struct {...} CORBA_sequence_long;''. First of all, isn't this gratuitously confusing? Why isn't it stated as typedef long FRED; typedef sequence FredSeq; is ``mapped onto `typedef CORBA_long FRED; typedef struct {...} CORBA_sequence_long; typedef CORBA_sequence_long FredSeq;'''? Secondly, suppose another sequence type is defined thusly: typedef sequence AnotherFredSeq; Is another (somehow different) struct definition to be generated as `typedef struct {...} CORBA_sequence_long;' that has different semantics? Won't this cause problems for the compiler :-? Bill From geoff Wed Sep 11 13:57:32 1996 Received: by amethyst.omg.org.omg.org (5.4R2.01/1.34) id AA06060; Wed, 11 Sep 1996 13:57:32 -0400 Date: Wed, 11 Sep 1996 13:57:32 -0400 From: geoff (Geoffrey Speare) Message-Id: <9609111757.AA06060@amethyst.omg.org.omg.org> To: issue-logger@omg.org Subject: RE: C mapping: confusing sequence example X-Omg-Issue: 108 Date: Tue, 10 Sep 1996 11:47:27 +0100 Alternate-Recipient: Allowed From: C.Wood@slh0633.wins.icl.co.uk To: Bill Janssen Cc: issues@omg.org, orbos@omg.org In-Reply-To: Subject: RE: C mapping: confusing sequence example Mime-Version: 1.0 --ga2rm0XsgIEzHOuQJzALan1dkJIA3vDS Content-type: text/plain; charset="us-ascii" --ga2rm0XsgIEzHOuQJzALan1dkJIA3vDS Content-type: text/plain; charset="us-ascii" > In section 14-11, the sequence example > > typedef CORBA_long FRED; /* C */ > typedef sequence FredSeq; > > is defined to be ``mapped onto struct {...} CORBA_sequence_long;''. > First of all, isn't this gratuitously confusing? Why isn't it stated as > > typedef long FRED; > typedef sequence FredSeq; > > is ``mapped onto `typedef CORBA_long FRED; typedef struct {...} > CORBA_sequence_long; typedef CORBA_sequence_long FredSeq;'''? > > Secondly, suppose another sequence type is defined thusly: > > typedef sequence AnotherFredSeq; > > Is another (somehow different) struct definition to be generated as > `typedef struct {...} CORBA_sequence_long;' that has different > semantics? Won't this cause problems for the compiler :-? > Yes, fundamental ones. The alternative is only to define CORBA_sequence_long once, using the first definition encountered. But consider if the IDL definitions are actually: typedef enum { X, Y, Z } Fred; typedef sequence FredSeq; typedef enum { A, B, C } Bert; typedef sequence BertSeq; This will generate C definitions: typedef enum { X, Y, Z } Fred; typedef struct { ...., Fred* _buffer } CORBA_sequence_enum; typedef CORBA_sequence_enum FredSeq; typedef enum { A, B, C } Bert; typedef CORBA_sequence_enum BertSeq; This works, but it doesn't half cause my C compiler to complain about mismatched types. I'm lost as to what this part of the specification is trying to achieve. Wouldn't it be much simpler for it to specify that the generated C definitions in this case are: typedef enum { X, Y, Z } Fred; typedef struct { ...., Fred* _buffer } FredSeq; typedef enum { A, B, C } Bert; typedef struct { ...., Bert* _buffer } BertSeq; Regards. -- Chris Wood, ICL Object Software Labs, Observatory House, Windsor Rd, Slough, SL1 2EY, UK mailto:chris_wood@iclnet.co.uk tel:+44-1753-604311 --ga2rm0XsgIEzHOuQJzALan1dkJIA3vDS-- 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 108: Confusing sequence example Summary: The fact that a sequence of longs is to be mapped into a struct is very confusing. Discussion -- There does not seem to be any alternative approach. Since C does not have a sequence primitive the implied parameters, i.e. max length, current length and pointer to data, must be put some where and a struct seems like the obvious answer. Suggest we close it with no change. There is a typo in the section. The IDL code that introduces CORBA_long FRED & sequence FredSeq is commented to be C code. I'll fix it editorially unless someone tells me I'm misreading the lines.