[omniORB] Non-NULL terminated strings
Clarke Brunt
clarke.brunt at trafficmaster.co.uk
Tue May 27 12:35:04 BST 2008
David wrote:
> Currently I have
> this IDL representation:
>
> typedef sequence<octet> StringData;
> struct MyStruct {
> StringData s;
> };
>
> Then I define a function to convert a char * to a StringData:
>
> StringData *convert( char *char_p, int len ) {
> CORBA::Octet *chars = new CORBA::Octet[len];
> for ( int i = 0; i < len; i++ ) {
> chars[i] = char_p[i];
> }
> return new StringData(len, len, chars, false);
> }
>
> It is then used like this:
>
> void foo( char *p, int len ) {
> struct MyStruct myStruct;
> myStruct.s = StringData_var( convert( p, len ) );
> // ... do stuff
> }
>
> Now my question is, is the memory I have allocated here with the new
> StringData and new Octet freed when foo() returns? How much does the
> StringData_var take care of -- i.e., does it free the Octets? Could
> someone clarify the meaning of the fourth parameter to new
> StringData()? I have a feeling that it might be relevant here.
You really need to read (if you haven't) the C++ language mapping
specification - very likely to leak something if you haven't fully
understood them.
Just writing off the top of my head here, so some risk that _I'll_ get
it wrong as well.
That final contructor parameter: you're using the default 'false', which
means that the sequence will _not_ do memory management of the supplied
buffer. So I reckon at best you're going to leak the char array. It
would stand a better chance with 'true'.
But if you're going to let sequences manage memory that you have
allocated, then you're supposed to use allocbuf to allocate it (rather
than 'new'), to be certain that it matches with the freebuf that the
sequence will do.
Rather than allocating your own buffer at all, why not just set the
sequence to the correct length, and then fill its own buffer, i.e.
StringData *convert( char *char_p, int len ) {
// Use a _var just as good practice - freed if we happened to get an
exception before returning
StringData_var s = new StringData(len);
for ( int i = 0; i < len; i++ ) {
s[i] = char_p[i];
}
return s._retn();
}
Or if you thought that repeated use of operator[] on the sequence was a
bit inefficient, then use get_buffer to obtain a pointer to its buffer.
Now your StringData_var in foo: It will delete the sequence when it goes
out of scope, but with your code won't delete the chars because of that
'false'. But I reckon its presence is completely pointless. It's doing
no harm, but is just wasting the construction/destruction of the _var
and the copy into the structure member, which will do its own memory
management.
So just do:
myStruct.s = convert( p, len );
Clarke Brunt
TRAFFICMASTER PLC
UNIT 22 / ST. JOHN'S INNOVATION CENTRE
COWLEY ROAD / CAMBRIDGE / CB4 0WS
T: 01223 422469
F:
E: clarke.brunt at trafficmaster.co.uk
Please consider the environment before printing this email. --------------------------------------------------------
Trafficmaster PLC is a limited Company registered in England and Wales.
Registered number: 2292714 Registered office: Martell House, University Way, Cranfield, BEDS. MK43 0TR
This message (and any associated files) is intended only for the use of omniorb-list at omniorb-support.com and may contain information that is confidential, subject to copyright or constitutes a trade secret. If you are not omniorb-list at omniorb-support.com you are hereby notified that any dissemination, copying or distribution of this message, or files associated with this message, is strictly prohibited. If you have received this message in error, please notify us immediately by replying to the message and deleting it from your computer. Any views or opinions presented are solely those of the author clarke.brunt at trafficmaster.co.uk and do not necessarily represent those of the company.
Warning: Although the company has taken reasonable precautions to ensure no viruses are present in this email, the company cannot accept responsibility for any loss or damage arising from the use of this email or attachments.
--------------------------------------------------------
More information about the omniORB-list
mailing list