Strlcpy is certainly an equal opportunity solution -- it's not available on
EITHER of the platforms I am working with.
My impression is that strcpy_s does *not* copy anything if the target buffer
is too short.
Hey, anybody want my implementations of a safe strcpy and sprintf? Here you
go:
// sprintf_ss is a "local" one-for-one replacement for Microsoft sprintf_s
// replace all references to sprintf_ss when/if IBM implements on z/OS
int sprintf_ss(char *string, size_t sizeInBytes, const char *format, ...)
{
va_list args;
assert(format != NULL);
//assert(string != NULL); // not necessary; hardware
will detect
va_start(args, format);
int ret = vsprintf(string, format, args);
va_end(args);
assert(strlen(string) < sizeInBytes); // note that the damage is
already done!
return ret;
}
// strcpy_ss is a "local" one-for-one replacement for Microsoft strcpy_ss
// replace all references to strcpy_ss when/if IBM implements on z/OS
// note not quite one-to-one as uses assert() rather than error returns
errno_t strcpy_ss(char *strDestination, size_t numberOfElements, const char
*strSource)
{
assert(strlen(strSource) < numberOfElements);
//assert(strDestination != NULL); // not necessary;
hardware will catch
assert(strSource != NULL);
strcpy(strDestination, strSource);
return 0;
}
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Gainsford, Allen
Sent: Sunday, December 06, 2009 11:56 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Safe C++ char array functions (Was " Is there a good mailing
list or forum for mainframe C/C++ specifically?")
> Correct on strcpy_s versus strncpy. Strncpy has the possibility of making
a
> new bad situation while preventing another. You can easily end up with a
> string that is guaranteed to "run wild" if you strcpy it.
I personally have always preferred strlcpy to strncpy or strcpy_s, since
strlcpy is basically an "always-safe" copy function that doesn't have the
defects of strcpy_s (does nothing if the dest is too small, instead of
copying as much as it safely can) or strncpy (doesn't always null-terminate
the result; and always touches every byte of the dest area, which can be a
massive time-waster for large dest buffers).
The only problem with strlcpy is that it's not supported on many platforms,
any more than strcpy_s is...
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
