Board index » cppbuilder » Re: is there a limit on str(n)cpy? One other note:

Re: is there a limit on str(n)cpy? One other note:


2005-08-05 09:58:33 PM
cppbuilder106
in the read() function, it blows up on the first strcpy. THe
other code with the string class and all is just me trying some
alternatives. Sorry for the extra code, it does blow up on the
FIRST call of strcpy.
"peter" < XXXX@XXXXX.COM >wrote:
Quote

here is a more thorough section of the code:

//this is the section where i make the call to read();
#define BUFFERSIZE 150
char *test;
int passes = 0;
int returnvalue = 1;
FILE *output = fopen("outputfile.txt","wb");
while(true){
passes++;
if(passes%1000 == 0){
printf("%d passes\n",passes);
}//end if
returnvalue = read(test);
if(returnvalue==0)
break;

fwrite(test,returnvalue,1,output);
}//end while
fclose(output);


//here is the actual function read() itself:

int read(char *end){
//when we enter this function, we assume that the zipfile is already open and ready for reading
if(done){
return 0;
}//end
static int currentEntryNumber = 0;
char buffer[BUFFERSIZE];
int result = 0;
result = UnzipItem(zipFile,currentEntryNumber,&buffer,sizeof(buffer));

if(result==0){
//the program does not even reach this section, so i left it out
}else{
strcpy(end,buffer);
string bytes(buffer);
strncpy(end,(char*)bytes.substr(0).c_str(),BUFFERSIZE);
totalBytesReadFromCurrentEntry += BUFFERSIZE;
return BUFFERSIZE;
}

by the way, the function UnzipItem is from an unzipping library.
It reads 'sizeof(buffer)' bytes into buffer, from the
'currentEntryNumber' zip entry in the 'zipFile' zip File.

so, the problem is that when i changed the constant 'BUFFERSIZE'
to anything over 150 or so ( i haven't nailed down the exact number, though i guess i ought to. 200 doesn't work) i get an access violation with that pretty grey screen that looks like the world is coming to an end and has assembly on it.

Any ideas? Thanks




Chris Uzdavinis (TeamB) < XXXX@XXXXX.COM >wrote:
>"Peter" < XXXX@XXXXX.COM >writes:
>
>>hi, i am trying to do a strcpy on using a big destination buffer.
>>I want the buffer to be as big as possible, hopefully 500000 bytes.
>>However, i can settle for something much less than that if i have
>>to. However, I am getting errors when i try to copy anything over about 150 bytes. Here are some snippets of code:
>>
>>void main(){
>
>Not related to your problem, but main *must* return an int or your
>program has undefined behavior.
>
>>//do some useful stuff
>>
>>returnvalue = read(test);
>>
>>//do some useful stuff
>
>There is far too much code omitted to enable anyone to do any
>practical analysis of your problem. It's imperative that you provide
>actual code that demonstrates the problem! If you strip it down to a
>skeleton that doesn't accurately reproduce the problem when run, we
>have to guess what is in the omitted sections. (Your job is to make a
>minimal example (< 50 lines) that is still complete enough to show the
>problem if we were to run it on our machines, unmodified.)
>
>>}//end main
>>
>>int read(char *end){
>>
>>//read some bytes into buffer...
>>strcpy(end,buffer);
>>
>>}//end function
>
>You say read some bytes into buffer, but strcpy isn't a byte-copy
>function, it's a STRING copy function. If your buffer doesn't end
>with a null termination byte, you'll run past the end of the buffer
>until it happens to stumble across one. Also, if there is a null
>anywhere in the "middle" of the buffer, strcpy will stop there.
>
>Unless you're really copying strings, this is simply the wrong
>function.
>
>Worse, your read function is writing an unknown amount of memory into
>a buffer of unknown size. That's a recipie for disaster. Whenever
>you pass a buffer around via pointer, you must also pass around the
>size of the buffer it points to. Otherwise your function has no hope
>of ensuring correctness.
>
>Further, strcpy is dangerous in that it does not consider the length
>of the target buffer. This is why you need to pass the length of
>"end" into the read function: so the read function can pass the length
>into the memcpy function, which is what you actually should be using,
>I think.
>
>>it is so weird, if buffer has 150 bytes it will work fine, but if i
>>up its content to 200 bytes it blows up on me. What's the deal?
>
>Without an actual example, all we can do is guess, but I think that
>you have multiple problems. As said above, you're treating a binary
>blob of data as a string (which it isn't), and worse, you're not
>dealing with buffer sizes at all.
>
>Maybe you have other problems too, in the code you didn't post.
>
>--
>Chris (TeamB);

 
 

Re:Re: is there a limit on str(n)cpy? One other note:

peter wrote:
Quote

in the read() function, it blows up on the first strcpy. THe
other code with the string class and all is just me trying some
alternatives. Sorry for the extra code, it does blow up on the
FIRST call of strcpy.
There are two factors that will contribute to your problem;
1) The pointer to char passed to read() is uninitialised (the basic
principle is that declaring a pointer does not implictly declare
anything for the pointer to point at). strcpy(end, buffer) will
therefore yield undefined behaviour.
2) Your UnzipItem() function probably does not append a trailing zero
to the end of buffer, Hence the strcpy() function will copy bytes
until it encounters a zero. Which (if end was actually pointing at
some array) would mean you will eventually fall off the end.
Quote



"peter" < XXXX@XXXXX.COM >wrote:
>
>here is a more thorough section of the code:
>
>//this is the section where i make the call to read();
>#define BUFFERSIZE 150
>char *test;
>int passes = 0;
>int returnvalue = 1;
>FILE *output = fopen("outputfile.txt","wb");
>while(true){
>passes++;
>if(passes%1000 == 0){
>printf("%d passes\n",passes);
>}//end if
>returnvalue = read(test);
>if(returnvalue==0)
>break;
>
>fwrite(test,returnvalue,1,output);
>}//end while
>fclose(output);
>
>
>//here is the actual function read() itself:
>
>int read(char *end){
>//when we enter this function, we assume that the zipfile is
>already open and ready for reading if(done){
>return 0;
>}//end
>static int currentEntryNumber = 0;
>char buffer[BUFFERSIZE];
>int result = 0;
>result =
>UnzipItem(zipFile,currentEntryNumber,&buffer,sizeof(buffer));
>
>if(result==0){
>//the program does not even reach this section, so i left
>it out }else{
>strcpy(end,buffer);
>string bytes(buffer);
>strncpy(end,(char*)bytes.substr(0).c_str(),BUFFERSIZE);
>totalBytesReadFromCurrentEntry += BUFFERSIZE;
>return BUFFERSIZE;
>}
>
>by the way, the function UnzipItem is from an unzipping library.
>It reads 'sizeof(buffer)' bytes into buffer, from the
>'currentEntryNumber' zip entry in the 'zipFile' zip File.
>
>so, the problem is that when i changed the constant 'BUFFERSIZE'
>to anything over 150 or so ( i haven't nailed down the exact
>number, though i guess i ought to. 200 doesn't work) i get an
>access violation with that pretty grey screen that looks like the
>world is coming to an end and has assembly on it.
>
>Any ideas? Thanks
>
>
>
>
>Chris Uzdavinis (TeamB) < XXXX@XXXXX.COM >wrote:
>>"Peter" < XXXX@XXXXX.COM >writes:
>>
>>>hi, i am trying to do a strcpy on using a big destination buffer.
>>>I want the buffer to be as big as possible, hopefully 500000
bytes.>>>However, i can settle for something much less than that
if i have>>>to. However, I am getting errors when i try to copy
anything over about 150 bytes. Here are some snippets of code:
>>>
>>>void main(){
>>
>>Not related to your problem, but main must return an int or your
>>program has undefined behavior.
>>
>>>//do some useful stuff
>>>
>>>returnvalue = read(test);
>>>
>>>//do some useful stuff
>>
>>There is far too much code omitted to enable anyone to do any
>>practical analysis of your problem. It's imperative that you
>>provide actual code that demonstrates the problem! If you strip
>>it down to a skeleton that doesn't accurately reproduce the
>>problem when run, we have to guess what is in the omitted
>>sections. (Your job is to make a minimal example (< 50 lines)
>>that is still complete enough to show the problem if we were to
>>run it on our machines, unmodified.)
>>
>>>}//end main
>>>
>>>int read(char *end){
>>>
>>>//read some bytes into buffer...
>>>strcpy(end,buffer);
>>>
>>>}//end function
>>
>>You say read some bytes into buffer, but strcpy isn't a byte-copy
>>function, it's a STRING copy function. If your buffer doesn't end
>>with a null termination byte, you'll run past the end of the
>>buffer until it happens to stumble across one. Also, if there is
>>a null anywhere in the "middle" of the buffer, strcpy will stop
>>there.
>>
>>Unless you're really copying strings, this is simply the wrong
>>function.
>>
>>Worse, your read function is writing an unknown amount of memory
>>into a buffer of unknown size. That's a recipie for disaster.
>>Whenever you pass a buffer around via pointer, you must also pass
>>around the size of the buffer it points to. Otherwise your
>>function has no hope of ensuring correctness.
>>
>>Further, strcpy is dangerous in that it does not consider the
>>length of the target buffer. This is why you need to pass the
>>length of "end" into the read function: so the read function can
>>pass the length into the memcpy function, which is what you
>>actually should be using, I think.
>>
>>>it is so weird, if buffer has 150 bytes it will work fine, but if
i>>>up its content to 200 bytes it blows up on me. What's the deal?
>>
>>Without an actual example, all we can do is guess, but I think
>>that you have multiple problems. As said above, you're treating
>>a binary blob of data as a string (which it isn't), and worse,
>>you're not dealing with buffer sizes at all.
>>
>>Maybe you have other problems too, in the code you didn't post.
>>
>>--
>>Chris (TeamB);
>
 

Re:Re: is there a limit on str(n)cpy? One other note:

On 5 Aug 2005 06:58:33 -0700, peter wrote:
Quote
result = UnzipItem(zipFile,currentEntryNumber,&buffer,sizeof(buffer));
what is the signature of UnzipItem?
you're passing it the address of buffer, i.e., char *[]. My guess is
that UnzipItem takes char *, so you should pass buffer (without the
ampersand '&')
--
liz
 

{smallsort}

Re:Re: is there a limit on str(n)cpy? One other note:

On 5 Aug 2005 06:58:33 -0700, peter wrote:
Quote
>>strcpy(end,buffer);
Oh, and as you know, end is a raw pointer not going anywher.
--
liz