Issue 109: Malloc problems with sequence types (c_mapping-rtf) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: The C mapping allocation procedures (T__alloc()) don"t allow for malloc"ing space for both the header struct and the values in one call. 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: It does not seem like the requested operation should provide. There are cases where the combined operation would be wrong. Therefore two operations would have to be specified. That would be a change to existing implementations, which are not supported very actively now. I doubt such a change would be implemented. End of Annotations:===== From geoff Wed Sep 11 13:34:39 1996 Received: by amethyst.omg.org.omg.org (5.4R2.01/1.34) id AA05479; Wed, 11 Sep 1996 13:34:39 -0400 Date: Wed, 11 Sep 1996 13:34:39 -0400 From: geoff (Geoffrey Speare) Message-Id: <9609111734.AA05479@amethyst.omg.org.omg.org> To: issue-logger@omg.org Subject: C mapping: malloc problems with sequence types X-Omg-Issue: 109 Date: Mon, 9 Sep 1996 17:20:10 PDT Sender: Bill Janssen From: Bill Janssen To: issues@omg.org Subject: C mapping: malloc problems with sequence types Cc: orbos@omg.org One thing commonly useful with sequences is a function that allows one to malloc space for both the header struct and the values in one call. However, the prescribed allocation procedures for sequences are only T__alloc(), which doesn't take a `size' parameter, and CORBA_sequence_T_allocbuf(), which doesn't allocated the header. Personally, I'd change the T__alloc() def for sequences to take an "unsigned long" parameter which would be an initial number of values to allocate for the sequence. 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 109 - Sequence allocation --------- I mostly agree with Bill's suggested resolution, except that I have a problem with bound sequences: It does not seem correct to be able to allocate a sequence buffer of arbitrary length if the sequence is constrained. Of course, you can always take a "buyer beware" stance, which in general seems to be what the C mapping does with bound sequences and strings. 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 109: Malloc problems with sequence types Summary: The C mapping allocation procedures (T__alloc()) don"t allow for malloc"ing space for both the header struct and the values in one call. Discussion - To me it does not seem like they should provide the requested operation. I can imagine places where I would not like the combined operation so if it were changed we would have to make it optional. That would be a change to existing implementations, which are not supported very actively now. I doubt such a change would be implemented so why do it. Suggest we close it with no change.