memcpy limitations?


Reputable Poster
Is there a limitation on the size of a string in the memcpy function? The BSFN I'm calling has the following variables defined:

typedef struct tagDSD5534A10B
JCHAR szFlatFileName[121];
ID idFilePtr;
JCHAR szFlatFileRecord[1501];
MATH_NUMERIC mnRecordLength;
JCHAR cSuppressErrorMessage;
JCHAR cErrorCode;
JCHAR szErrorMessageID[11];
} DSD5534A10B, *LPDSD5534A10B;

int nRecordLength=0;
JCHAR szRecord[1501];

Inside the BSFN there is the following call to memcpy:
memcpy(lpDS->szFlatFileRecord, szRecord, nRecordLength)

When I walk through in debug, the full string is contained in szRecord and nRecordLength is 400. However, after the call to memcpy the resulting szFlagFileRecord has a copy of szRecord truncated at 200 characters.

I didn't write the BSFN with this code, but I'm trying to call it from a UBE. I'm confused that the results are being truncated. It looks like everything is defined big enough, so I'm wondering if there is a limitation on memcpy itself.



Legendary Poster
To answer you original question, no, there shouldn't be a limitation on memcpy other than the maximum size of size_t which s/b a 32bit unsigned integer - so effectively no limitation.

Now, as for that line of code you referenced. My guess is that this code worked with non-unicode strings but now does not with unicode. If the intent was to copy the full szRecord to lpDS->szFlatFileRecord and szRecord does in fact contain a unicode string then:

memcpy(lpDS->szFlatFileRecord, szRecord, nRecordLength);

should probably be written as:

jdeStrncpy(lpDS->szFlatFileRecord, szRecord, DIM(lpDS->szFlatFileRecord)-1);


Reputable Poster
Thanks Brian. I was beginning to suspect it might have something to do with number of bytes and unicode characters being 2 bytes. For a quick check, I switched my record length to 800 and it no longer truncated. I will follow up with actually fixing our BSFN.

Thanks again,