String handling

Hi,

I'mn debugging an ISAPI wildcard extension used on sharepoint 2001 document libraries.  Basically the code works fine for its main function (creating an audit) but has a conflict of some sort weith the Sharepoint indexing program.  


I found one area where there was a problem and now I have another one!  I have the following code which I put in during debug but want to keep in some form or other -

LPSTR x = (LPSTR) pecb->lpbData;  //pecb->lpbData is of type LPBYTE
string sBrowserCheckoutTest = x;

Basically the problem is that the first line is 'okay'

LPSTR x = (LPSTR) pecb->lpbData;  //pecb->lpbData is of type LPBYTE

but if I add the second line (let alone actually do anything with sBrowserCheckoutTest ) I get an error in the System events log when I run a Sharepoint crawl (index).  I don't know what the error is but it causes a warning to be generated about the application pool.

What I was wondoring is whether it is obvious to anyone whgy this should be ?  I assume this is unlikely so the other question is to ask if someone could

a) confirm that sBrowserCheckoutTest is still in effect a pointer to the original data structure and
b) give me a simple bit of code to copy the byte array (pecb->lpbData ) into a local char array (if possible allowing for the fact that pecb->lpbData can be of varying sizes!!!) so that I am only performing one quick operation on the original data structure.

I would be very grateful if this is possible for anyone to do ... !

Thanks,

Ben.


gringogordoAsked:
Who is Participating?
 
balderCommented:


LPSTR x = (LPSTR) pecb->lpbData;
std::string sBrowserCheckoutTest( x, pecb->lpbDataSize );

guessing you have a pecb->lpbDataSize that tells the size of lpbData.
0
 
itsmeandnobodyelseCommented:
>>>> string sBrowserCheckoutTest = x;

The assignment operator of std::string needs a terminating zero character. If lpbData contains binary data or was read from a stream where no zero character was set, the assignment might read beyond buffer size (what may be is an explanation of the warning).

Regards, Alex
0
 
itsmeandnobodyelseCommented:
>> give me a simple bit of code to copy the byte array (pecb->lpbData ) into a local char array

   int siz = pecb->lpbDataSize;            // assume you know the size of your data
   LPSTR pstr = new char[siz+1];        // add 1 for terminating zero
   memcpy(pstr, pecb->lpbData, siz);   // copy data
   pstr[siz] = '\0';                               // add the zero character

   .....


   delete [] pstr;        

Note, I would recommend to copy it to a std::string as balder has showed you.

Regards, Alex
                   

0
Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

 
gringogordoAuthor Commented:
Hi,

Sorry can I just check that I understand what is going on.

1 - std::string sBrowserCheckoutTest( x, pecb->lpbDataSize );  
    ->creates a new char array and copies the exisiting data (x) into it.
2 - string sBrowserCheckoutTest = x;
    -> creates a pointer to the exisiting data

Also

an interesting yet upsetting occurance is that performing the operation in one line stops the warning/error from happening

sDataCheck = (LPSTR) pecb->lpbData;

Is this maybe because (as per itsmeandnobodyelse) there is no null terminator in the byte array and when performing the operation directly like this the string class handles that.  Or is it because I'm allergic to silicon chips ?

Thanks,

Ben.
0
 
balderCommented:


1 - std::string sBrowserCheckoutTest( x, pecb->lpbDataSize );  
    ->creates a new char array and copies the exisiting data (x) into it.
yepp

2 - string sBrowserCheckoutTest = x;
    -> creates a pointer to the exisiting data
tries to create a new char array, but doesn't know when to stop -> crash

sDataCheck = (LPSTR) pecb->lpbData;

what is sDataCheck?

 LPBYTE sDataCheck;   - then you just get a pointer to the data area
string sDataCheck;  - then you just was lucky, it will no work


0
 
grg99Commented:
I'd at the very least make sure "x" isnt coming back as NULL.

Then when you're sure it isnt NULL, check to see if its strlen() is reasonable-- maybe somebody forgot to put a terminating '\0' on it.

0
 
itsmeandnobodyelseCommented:
>>>> Or is it because I'm allergic to silicon chips ?

It really seems so as the issue sounds strange  ;-)

There are very few differences between

    LPSTR x = (LPSTR) pecb->lpbData;  //pecb->lpbData is of type LPBYTE
    string sBrowserCheckoutTest = x;

and

    string sDataCheck;
    sDataCheck = (LPSTR) pecb->lpbData;


<<<< LPSTR x = (LPSTR) pecb->lpbData;

Here a debug compilation may find out that lpbData isn't a null-terminated text string within the allocated boundaries of the data buffer.

>>>> sDataCheck = (LPSTR) pecb->lpbData;

That makes a strlen (search for the terminating zero from left to right) on the buffer in lbpData. Cause strlen is a C runtime function it doesn't make a check on buffer boundaries (both Debug and Release). However, if there wasn't a zero character by accident, you would/should see any garbage (unprintable characters) at the end of the string if buffer size was exceeded.

If you couldn't detect such garbage, I would think that the one-liner works by accident, i. e. by changing your code, the data buffer accidantly was initialized by zeroes thus making the text buffer a zero terminated string.

Regards, Alex
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.