Issue 111: Inout sequence/any behavior with oversized return values (c_mapping-rtf) Source: (, ) Nature: Uncategorized Severity: Summary: Summary: In case 5 of table 22 in section 14.19, what is the specified behavior if the release flag is FALSE, but the value to be returned is longer than the value specified? Resolution: Revised Text: Actions taken: September 11, 1996: Received issue December 12, 1996: moved from cxx_revision to c-rev-wg Discussion: End of Annotations:===== From geoff Wed Sep 11 13:49:30 1996 Received: by amethyst.omg.org.omg.org (5.4R2.01/1.34) id AA05805; Wed, 11 Sep 1996 13:49:30 -0400 Date: Wed, 11 Sep 1996 13:49:30 -0400 From: geoff (Geoffrey Speare) Message-Id: <9609111749.AA05805@amethyst.omg.org.omg.org> To: issue-logger@omg.org Subject: C mapping: inout sequence/any behavior with oversized return values? X-Omg-Issue: 111 Date: Mon, 9 Sep 1996 17:23:26 PDT Sender: Bill Janssen From: Bill Janssen To: issues@omg.org Subject: C mapping: inout sequence/any behavior with oversized return values? Cc: orbos@omg.org In case 5 of table 22 in section 14.19, what is the specified behavior if the release flag is FALSE, but the value to be returned is longer than the value originally supplied? Is the value of _buffer dropped on the floor? (Wouldn't this lead to memory leaks?) Is an error returned? 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 Issue 111 - inout sequence/any behavior --------- I don't think the specified behavior introduces any new problems. Having the runtime blithely overwrite the previous pointer value is entirely consistent with the behavior of the release flags vis a vis CORBA_Free. Nor is there any error here. If you've set the release flag to FALSE, you'd better be planning on managing the memory yourself through some other means. A likely scenario is a sequence buffer off the stack. Obviously, I don't want the system to deallocate it just because it has created a new one. Rather, the buffer should be replaced AND THE RELEASE FLAG MODIFIED. I don't think this is explicitly stated anywhere and it probably should be (see recently filed issue on this subject). >From mail Fri Jan 31 16:30 EST 1997 Date: Fri, 31 Jan 1997 13:25:03 PST Sender: Bill Janssen From: Bill Janssen To: issues@omg.org, c-reg-wg@omg.org Subject: [C WG issue]: return values on exceptional return Cc: spreitzer.PARC@xerox.com References: <97Jan31.125448pst."15698(4)"@alpha.xerox.com> Content-Length: 692 From: Mike_Spreitzer.PARC@xerox.com This discussion raises a question that I just failed to find an answer to in my CORBA 2.0 spec: in the C mapping, what are the caller's responsibilities wrt storage management of OUT & INOUT parameters and return results after an exception is raised? Or in general, does raising an exception mean that, abstractly speaking, no other values (besides the exception's members) are being returned? An answer to these questions would tell us what to do. I expect the answer is that the intent of CORBA is that when an exception is raised, no other values are returned. So in the C mapping, the caller is expected to, e.g., *not* free any return results. 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 111: Inout sequence/any behavior with oversized return values Summary: In case 5 of table 22 in section 14.19, what is the specified behavior if the release flag is FALSE, but the value to be returned is longer than the value specified? Discussion - This seems to be an unspecified behavior. A release flag of 'false' indicates that the client SW has allocated space for the sequence/any case 5 in the table is defining what should happen if the server needs to return more data than is permissible. Since ORB really can't free user space and reallocate it, I would think that the operation should end with an exception. However I can't find text to that effect and I haven't located our programmer to see what we did so at this point I have no suggested action. I'll get something out tomorrow and if anyone else wants to contribute a solution I'm open to it.