   problem with strcpy()
  I am having an interesting problem with strcpy().  I am using C++ Builder for this. Here is the code: //length specs for fields#define FN_LEN10#define DESC_LEN   20struct TileInfo{  intID; //tile ID, used for selecting proper tile bitmap  char    FileName[FN_LEN];   //the filename for the tile  char    Description[DESC_LEN];  //tile description};...TileInfo* tile = new TileInfo;strcpy(tile->FileName,Filename->Text.c_str());strcpy(tile->Description,Description->Text.c_str());...Filename and Description are edit boxes. Ok now the problem. The first call to strcpy works fine but the second adds Description to the end of tile->FileName. ex. FileName->Text = "blue.bmp" Description->Text ="square" after first copy tile->Filename will equal blue.bmp after second copy tile->Filename will be blue.bmpsquare  while tile->Description will be square. If I reverse the copy order then description stays empty and filename is correct. Any ideas to what is going on?  
  I assume you''re using char arrays for a good reason, so I''ll avoid talking about THAT more...check that the string you''re strcpy()''ing from contains the correct values.check that the strings you''re strcpy()''ing from are not bigger than *_LEN - 1 and leave this code in your program forever.make sure you didn''t change the code around any when you posted this... like say, really using a strncpy() in the original code? ;  I have my reasons for the char arrays.Both contain the correct source strings as these are edit boxes.  I have verified this through the debugger also.  The length is also correct because the edit''s are limited to there sizes.  I pasted the code right out of my source so nothing was changed. ;fprintf(log, "tile->FileName: %s", tile->Filename);fprintf(log, "tile->Description: %s", tile->Description);fprintf(log, "Filename->Text.c_str(): %s", Filename->Text.c_str());fprintf(log, "Description->Text.c_str(): %s", Description->Text.c_str());if (FN_LEN > strlen(Filename->Text.c_str()))   fprintf(log, "Warning, strlen(Filename->Text.c_str()):%d greater than FN_LEN:%d", strlen(Filename->Text.c_str()), FN_LEN);else if (DESC_LEN > strlen(Description->Text.c_str()))   fprintf(log, "Warning, strlen(Description->Text.c_str()):%d greater than DESC_LEN:%d", strlen(Description->Text.c_str()), DESC_LEN);/* your code */  I''d also check the callback that updates Filename and Description and ensure they are being set properly. ;  Are you using unicode for anything?  Maybe are putting unicode characters into chars?  It sounds like some sort of buffer overrun in your strcpy.  I would suggest doing a length check to make sure you have enough room to fit your string into your buffer.  Also make sure that the size of the type held by Filename->Text is the same as the size of your buffer.  ie sizeof(Filename->Text.c_str()[0]) == sizeof(FileName[0])Yes, these are shots in the dark.  ;  It seems pretty simple - one of the more classic buffer overflows.  strcpy() copies all the characters it finds starting at the address you give it, up to and *including* the first null byte (\0) it finds.  Not very safe, but hey - if you're careful...This is fine if you're file name is 9 chars long - we can still fit the null byte into the buffer.  What if it's 10 chars long?  Well in this instance, that null byte gets written to the first byte of the next buffer - 'Description'.  That then gets overwritten by the second strcpy () call.  Ooops.  Where once we had two buffers, of 10 and 20 bytes respectively which we could print individually, we now have one of 10 + strlen(description).  When you call a function that looks for a terminating null byte (printf, strcpy, sprintf - ouch!) it'll not find a terminating null byte until it reaches the end of the description.  In the beginning, the memory was desolate and void (ack - that's too close to a pun for my liking)  Here's a diagram :Start::.0000000000  // file name00000000000000000000  // description  Teh someone started using strcpy() and all hell let loose...Nine letter file name ::.black.exe0  // file namea description0000000  // descriptionprintf("%s",TitleInfo.fileName) = 'black.exe'printf("%s",TitleInfo.description) = 'a description'.Ten letter filename ::.yellow.exe  // file namea description0000000  // descriptionprintf("%s",TitleInfo.fileName) = 'yellow.exea description'printf("%s",TitleInfo.description) = 'a description'  Notice the lack of a '0' between the two buffers in the last example.If you're placing your struct on the stack, i.e. you define it something like this -void myFunc(void){   struct TitleInfo TI;   //code goes here   return;}   then you have *big* problems (like your program crashing.  If you're lucky.... Failing that someone overwrites the stored eip on the stack and starts executing arbitrary code)Lesson?  Control those buffers!  Do length checking, don't get fooled into off by one conditions like the one above, and don't use strcpy, sprintf etc - use the 'n' versions (like strncpy)  Here endeth todays lesson... [edited by - xf00f on August 1, 2003 4:47:01 PM];quote:Any ideas to what is going on? Yeah.  You''re demonstrating why you should be using std::string.quote:The length is also correct because the edit''s are limited to there sizes.If you''re using Win32 then your edit boxes cannot have their size effectively limited.  You must always *always* check. ;quote:If you''re using Win32 then your edit boxes cannot have their size effectively limited.Ummm - rearrange theses letters and see what you get -s,u,c,b,l,a,s,s...;quote:Original post by xf00f  Ummm - rearrange theses letters and see what you get -s,u,c,b,l,a,s,s...At which point you''re no longer using edit boxes but rather some control of your own devising.;quote:Original post by DrPizza  quote:Original post by xf00f   Ummm - rearrange theses letters and see what you get -s,u,c,b,l,a,s,s...At which point you''re no longer using edit boxes but rather some control of your own devising. What''s the harm in that? 