BorlandTalk.com Borland discussion newsgroups   Archives   FAQ   Search   Memberlist   Usergroups   Register   Profile   Log in to check your private messages   Log in  is there a limit on str(n)cpy? Goto page 1, 2  Next          BorlandTalk.com Forum Index -> C++ Builder (Language C++) View previous topic :: View next topic   Author Message Peter Guest Posted: Thu Aug 04, 2005 9:34 pm    Post subject: is there a limit on str(n)cpy? 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(){ //do some useful stuff returnvalue = read(test); //do some useful stuff }//end main int read(char *end){ //read some bytes into buffer... strcpy(end,buffer); }//end function 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? thanks Back to top Remy Lebeau (TeamB) Guest Posted: Thu Aug 04, 2005 9:38 pm    Post subject: Re: is there a limit on str(n)cpy? "Peter" <peterna (AT) attglobal (DOT) net> wrote Quote: hi, i am trying to do a strcpy on using a big destination buffer. strcpy() is dangerous, subject to buffer overflows. Always use strncpy() instead. Quote: I want the buffer to be as big as possible, hopefully 500000 bytes. Are you putting that large a buffer on the stack or the heap? You should use the heap for something that large. Quote: However, I am getting errors when i try to copy anything over about 150 bytes. You did not post enough code to diagnose your problem. Quote: returnvalue = read(test); What is 'test' declared as? Quote: strcpy(end,buffer); What is 'buffer' declared as? Quote: 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. Please elaborate. Is 'test' large enough to hold 200 characters in the first place? Gambit Back to top peter Guest Posted: Fri Aug 05, 2005 4:16 am    Post subject: Re: is there a limit on str(n)cpy? test is defined as char*, this gives it pretty much unlimited capacity, right? "Remy Lebeau (TeamB)" <no.spam (AT) no (DOT) spam.com> wrote: Quote: "Peter" <peterna (AT) attglobal (DOT) net> wrote in message news:42f289c8$1 (AT) newsgroups (DOT) borland.com... hi, i am trying to do a strcpy on using a big destination buffer. strcpy() is dangerous, subject to buffer overflows. Always use strncpy() instead. I want the buffer to be as big as possible, hopefully 500000 bytes. Are you putting that large a buffer on the stack or the heap? You should use the heap for something that large. However, I am getting errors when i try to copy anything over about 150 bytes. You did not post enough code to diagnose your problem. returnvalue = read(test); What is 'test' declared as? strcpy(end,buffer); What is 'buffer' declared as? 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. Please elaborate. Is 'test' large enough to hold 200 characters in the first place? Gambit Back to top Remy Lebeau (TeamB) Guest Posted: Fri Aug 05, 2005 4:24 am    Post subject: Re: is there a limit on str(n)cpy? "peter" <peterna (AT) attglobal (DOT) net> wrote Quote: test is defined as char*, this gives it pretty much unlimited capacity, right? No. For one thing, not all memory is accessible to begin with, the OS reserved portions of memory for its own use and does not allow applications to access it. Second, if you did not allocate any actually memory for the pointer to point to, then your code is undefined behavior waiting to crash. Which is why I asked you post your actual code so everyone can see what you are actually doing. It sounds like you are writing data into random memory through an uninitialized pointer. Gambit Back to top Liz Albin Guest Posted: Fri Aug 05, 2005 4:29 am    Post subject: Re: is there a limit on str(n)cpy? On 4 Aug 2005 14:34:00 -0700, Peter wrote: Quote: 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? thanks How large is end? I've certainly copied more than 150 bytes using strcpy or strncpy -- liz Back to top Liz Albin Guest Posted: Fri Aug 05, 2005 4:32 am    Post subject: Re: is there a limit on str(n)cpy? On 4 Aug 2005 21:16:36 -0700, peter wrote: Quote: test is defined as char*, this gives it pretty much unlimited capacity, right? what? With no size? you need something more like int read(char * end); int main() { char test[500]; int returnvalue = read(test); } int read(char * end) { // stuff char buffer[250]; int length; // set length somehow strncpy(end, buffer, length); return length; } -- liz Back to top Chris Uzdavinis (TeamB) Guest Posted: Fri Aug 05, 2005 1:33 pm    Post subject: Re: is there a limit on str(n)cpy? "Peter" <peterna (AT) attglobal (DOT) net> writes: Quote: 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. Quote: //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.) Quote: }//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. Quote: 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); Back to top Chris Uzdavinis (TeamB) Guest Posted: Fri Aug 05, 2005 1:36 pm    Post subject: Re: is there a limit on str(n)cpy? "peter" <peterna (AT) attglobal (DOT) net> writes: Quote: test is defined as char*, this gives it pretty much unlimited capacity, right? A pointer holds an address of a region of memory. While that region's it points to can be changed, at any given point in time it is always fixed as either 1) invalid or 2) some finite size (determined by however big the allocation was, or how big the array was declared, etc.) If you don't initialize the char*, the pointer holds invalid data. If you assign it the address of a buffer, then that buffer's size is as much as you're allowed to write. If you exceed that amount, your program will have undefined behavior. -- Chris (TeamB); Back to top Chris Uzdavinis (TeamB) Guest Posted: Fri Aug 05, 2005 1:42 pm    Post subject: Re: is there a limit on str(n)cpy? Liz Albin <lizalbinNotThis (AT) yahoo (DOT) com> writes: Quote: On 4 Aug 2005 21:16:36 -0700, peter wrote: test is defined as char*, this gives it pretty much unlimited capacity, right? what? With no size? you need something more like int read(char * end); int main() { char test[500]; int returnvalue = read(test); } int read(char * end) { // stuff char buffer[250]; int length; // set length somehow strncpy(end, buffer, length); return length; } But even this assumes that "end" is big enough to hold the data. When the caller and reciever are next to each other in the same file, this may be easy to confirm, but it's still dangerous in principle. int read(char * end); int main() { size_t const BUFSIZE=500; char test[BUFSIZE+1]; int returnvalue = read(test, BUFSIZE); } int read(char * end, size_t arg_len) { // stuff char buffer[250]; size_t length = ... (fill buf) ; length = std::min(length, arg_len); memcpy(end, buffer, length); return length; } If one wishes to be clever, the local buffer could be omitted. Knowing the size of the provided buffer offers a lot of opportunities for optimization and improved correctness. -- Chris (TeamB); Back to top peter Guest Posted: Fri Aug 05, 2005 1:56 pm    Post subject: Re: is there a limit on str(n)cpy? 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 passesn",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) <chris (AT) uzdavinis (DOT) com> wrote: Quote: "Peter" <peterna (AT) attglobal (DOT) net> 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); Back to top peter Guest Posted: Fri Aug 05, 2005 1:58 pm    Post subject: Re: is there a limit on str(n)cpy? One other note: 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" <peterna (AT) attglobal (DOT) net> 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 passesn",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) <chris (AT) uzdavinis (DOT) com> wrote: "Peter" <peterna (AT) attglobal (DOT) net> 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); Back to top Rob Guest Posted: Fri Aug 05, 2005 2:09 pm    Post subject: 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" <peterna (AT) attglobal (DOT) net> 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 passesn",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) <chris (AT) uzdavinis (DOT) com> wrote: "Peter" <peterna (AT) attglobal (DOT) net> 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); Back to top Chris Uzdavinis (TeamB) Guest Posted: Fri Aug 05, 2005 2:10 pm    Post subject: Re: is there a limit on str(n)cpy? "peter" <peterna (AT) attglobal (DOT) net> writes: Quote: //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 passesn",passes); }//end if returnvalue = read(test); Ok, thanks. test is not a valid address. You cannot pass it into read(), because test is uninitialized. You have to create a buffer (somewhere to actually hold data), and then associate test to it by assigning the address of the buffer to the test variable. For example: char buffer[BUFFERSIZE]; char * test = buffer; Now if you write into test, data is actually put into the "buffer" array. But given this situation, you can write directly into buffer for the same result, so the "test" variable is unnecessary. Or you could do this: char test[BUFFERSIZE]; Now test is not a pointer, but an actual array with actual (fixed amount) of size associated with it. Quote: 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; } This looks a bit strange. Why not just pass end and end's length (which you need to pass into read()), directly to UnzipItem, and then you won't have to copy the results from a temporary buffer. Now that we see that you're unzipping some arbitrary data, you CANNOT consider it a string, and cannot use any of the string functions (strcpy, strncpy, strlen, whatever.) If you need to copy it, you need to use memcpy, and know the exact length of the memory you're copying. (But if you read directly into end, you won't need to copy anything, which is a better design since it's faster.) PS, please don't quote the entire message, but only selectively include quoted text that is relevant to your current post. Thanks. -- Chris (TeamB); Back to top peter Guest Posted: Fri Aug 05, 2005 2:39 pm    Post subject: Re: is there a limit on str(n)cpy? Thanks for the ideas. I ended up changing the 'UnzipItem' line to: result = UnzipItem(zipFile,currentEntryNumber,end,BUFFERSIZE); as, I believe it was you, suggested earlier. Once you said it I realized that's what I should have been doing in the first place. It works marvelously now. Thanks for the help, I now realize that my knowledge of pointers is sorely lacking. Chris Uzdavinis (TeamB) <chris (AT) uzdavinis (DOT) com> wrote: Quote: "peter" <peterna (AT) attglobal (DOT) net> writes: //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 passesn",passes); }//end if returnvalue = read(test); Ok, thanks. test is not a valid address. You cannot pass it into read(), because test is uninitialized. You have to create a buffer (somewhere to actually hold data), and then associate test to it by assigning the address of the buffer to the test variable. For example: char buffer[BUFFERSIZE]; char * test = buffer; Now if you write into test, data is actually put into the "buffer" array. But given this situation, you can write directly into buffer for the same result, so the "test" variable is unnecessary. Or you could do this: char test[BUFFERSIZE]; Now test is not a pointer, but an actual array with actual (fixed amount) of size associated with it. 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; } This looks a bit strange. Why not just pass end and end's length (which you need to pass into read()), directly to UnzipItem, and then you won't have to copy the results from a temporary buffer. Now that we see that you're unzipping some arbitrary data, you CANNOT consider it a string, and cannot use any of the string functions (strcpy, strncpy, strlen, whatever.) If you need to copy it, you need to use memcpy, and know the exact length of the memory you're copying. (But if you read directly into end, you won't need to copy anything, which is a better design since it's faster.) PS, please don't quote the entire message, but only selectively include quoted text that is relevant to your current post. Thanks. -- Chris (TeamB); Back to top Chris Uzdavinis (TeamB) Guest Posted: Fri Aug 05, 2005 3:09 pm    Post subject: Re: is there a limit on str(n)cpy? "peter" <peterna (AT) attglobal (DOT) net> writes: Quote: Thanks for the ideas. I ended up changing the 'UnzipItem' line to: result = UnzipItem(zipFile,currentEntryNumber,end,BUFFERSIZE); as, I believe it was you, suggested earlier. Once you said it I realized that's what I should have been doing in the first place. It works marvelously now. Thanks for the help, I now realize that my knowledge of pointers is sorely lacking. That's closer to what I suggested, but very different still. When the read function receives a pointer, it cannot assume to know the size of the buffer the pointer points to! For example: void foo() { char buf[1000]; read(buf); } void bar() { char buf[50]; read(buf); } You cannot possibly make read() work correctly given the above two callers, because read is hard-coded to only work with buffers of a single size. That's an unrealistic restriction to put on people wishing to use your function, and will result in bugs. You need to change read to accept a pointer AND A LENGTH, and then read can work with an arbitrary-length buffer, because the caller who provides the pointer also knows how big it is, and passes in that value along side the buffer itself. In general, you should always strive to write code that is self-contained and doesn't depend on making accurate assumptions about what the caller is doing. If a function needs to know something about the caller, the caller should have to pass in that information. -- Chris (TeamB); Back to top Display posts from previous: All Posts1 Day7 Days2 Weeks1 Month3 Months6 Months1 Year Oldest FirstNewest First         BorlandTalk.com Forum Index -> C++ Builder (Language C++) All times are GMT Goto page 1, 2  Next Page 1 of 2   Jump to: Select a forum C++ Builder Newsgroups----------------C++ BuilderC++ Builder (ActiveX)C++ Builder (Announcements)C++ Builder (Command Line Tools)C++ Builder DatabasesC++ Builder Databases (ADO)C++ Builder Databases (Desktop)C++ Builder Databases (InterBase Express)C++ Builder Databases (Multi-Tier)C++ Builder Databases (SQL Servers)C++ Builder (Graphics)C++ Builder (IDE)C++ Builder (Internet)C++ Builder (Internet Socket)C++ Builder (Internet Web)C++ Builder (Jobs)C++ Builder (Language)C++ Builder (Language C++)C++ Builder (Compatibility with MFC)C++ Builder (Native API)C++ Builder (Non-Technical)C++ Builder (Students)C++ Builder (Third Party Tools)C++ Builder (Upgrade)C++ Builder (VCL)C++ Builder (VCL Components Usage)C++ Builder (VCL Components Development)C++ Builder (VCL Usage)C++ Builder (WinAPI)C++ Builder Installation Delphi Newsgroups----------------Delphi (General)Delphi ActiveX Controls UsageDelphi ActiveX Controls DevelopmentDelphi As400Delphi DatabasesDelphi Databases (ADO)Delphi Databases (dbExpress)Delphi Databases (Desktop)Delphi Databases (InterBase Express)Delphi Databases (Multi-Tier)Delphi Databases (SQL Servers)Delphi DeploymentDelphi GraphicsDelphi IDEDelphi InternationalizationDelphi InternetDelphi Internet Isapi-WebBrokerDelphi Internet WebSnapDelphi Internet WinsockDelphi JobsDelphi Language BASMDelphi Language ObjectPascalDelphi Model Driven Architecture (General)Delphi Model Driven Architecture (Third Party)Delphi MultimediaDelphi Native APIDelphi Non-TechnicalDelphi ObjectPascalDelphi OLE AutomationDelphi OO designDelphi OpenToolsAPIDelphi Reporting-ChartingDelphi RTLDelphi StudentsDelphi TeamSourceDelphi Thirdparty ToolsDelphi Thirdparty Tools (General)Delphi Thirdparty Tools (IntraWeb)Delphi Thirdparty Tools (RaveReports)Delphi UpgradeDelphi VCLDelphi VCL ComponentsDelphi VCL Components UsingDelphi VCL Components WritingDelphi WebServices SOAPDelphi WinAPIDelphi XMLDelphi Installationcomp.lang.pascal.delphi.components.misccomp.lang.pascal.delphi.components.usagecomp.lang.pascal.delphi.components.writingcomp.lang.pascal.delphi.databasescomp.lang.pascal.delphi.misccomp.sources.delphi JBuilder Newsgroups----------------JBuilderJBuilder AnnouncementsJBuilder Applet IssuesJBuilder As400JBuilder CompilerJBuilder CORBA/RMIJBuilder DatabasesJBuilder DB SwingJBuilder DebuggerJBuilder DeploymentJBuilder DocumentationJBuilder EnterpriseJBuilder HandheldJBuilder IDEJBuilder JavaJBuilder JavaAPIJBuilder Java LanguageJBuilder Java SwingJBuilder Java BeansJBuilder Java Beans UsageJBuilder Java Beans DevelopmentJBuilder JBCLJBuilder JDataStoreJBuilder JobsJBuilder LinuxJBuilder MacintoshJBuilder & MobileSetJBuilder MultiLingual AppsJBuilder Non-TechnicalJBuilder OpenToolsJBuilder Servlets (JSP)JBuilder StudentsJBuilder Team DevelopmentJBuilder Thirdparty ToolsJBuilder UpgradeJBuilder Installation InterBase Newsgroups----------------InterBaseInterBase Bug DiscussionInterBase GeneralInterBase IBConsoleInterBase OpenSourceInterBase ReplicationInterBase SQLInterBase ThirdpartyInterBase Installation Miscellaneous Borland Newsgroups----------------AppCenterAppServerEnteraVisiBroker  You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum Powered by phpBB © 2001, 2006 phpBB Group SEO toolkit © 2004-2006 webmedic.