I have just been reading the lists and realise that strncpyW/strncpy is bad news for some reason. Please consider this patch withdrawn.
Wouldn't it be better to implement strncpyW as a wrapper for memcpy? Given that all the other string functions are implemeted with the (W) version, having strncpyW missing is a bit confusing.
Jeff Latimer
Jeff Latimer wrote:
An implementation of strncpyW.
Jeff Latimer
Index: unicode.h
RCS file: /home/wine/wine/include/wine/unicode.h,v retrieving revision 1.31 diff -u -r1.31 unicode.h --- unicode.h 21 Apr 2005 17:18:50 -0000 1.31 +++ unicode.h 25 Apr 2005 10:48:05 -0000 @@ -191,6 +191,18 @@ return dst; }
+static inline WCHAR *strncpyW( WCHAR *dst, const WCHAR *src, int maxlen ) +{
- WCHAR *p = dst;
- if (maxlen > 0 )
- {
maxlen--;while (((*p++ = *src++) && maxlen--));- }
- if (*p) *p++ = (WCHAR) "\0";
- return dst;
+}
static inline int strcmpW( const WCHAR *str1, const WCHAR *str2 ) { while (*str1 && (*str1 == *str2)) { str1++; str2++; }
On 4/25/05, Jeff Latimer jeffl@defcen.gov.au wrote:
I have just been reading the lists and realise that strncpyW/strncpy is bad news for some reason. Please consider this patch withdrawn.
Wouldn't it be better to implement strncpyW as a wrapper for memcpy? Given that all the other string functions are implemeted with the (W) version, having strncpyW missing is a bit confusing.
Quoted from winehq.org Janitorial Page:
"strncpy(dst,src,n) has two subtle problems. The first is that it always fills the whole dst buffer (n characters). The second is that it doesn't always nul terminate the dst buffer that it's filling. Wine code should avoid the use of strncpy for these reasons, and instead use lstrcpynA/W or memcpy."
Thanks for that. I suppose that wrappering memcpy as as strncpy is not a good idea. To save confusion, would a comment in unicode.h to say "don't worry strncpyW is missing by design and that memcpy/lstrcpynA/W should be used instead" be a good precaution?
Jeff Latimer
James Hawkins wrote:
On 4/25/05, Jeff Latimer jeffl@defcen.gov.au wrote:
I have just been reading the lists and realise that strncpyW/strncpy is bad news for some reason. Please consider this patch withdrawn.
Wouldn't it be better to implement strncpyW as a wrapper for memcpy? Given that all the other string functions are implemeted with the (W) version, having strncpyW missing is a bit confusing.
Quoted from winehq.org Janitorial Page:
"strncpy(dst,src,n) has two subtle problems. The first is that it always fills the whole dst buffer (n characters). The second is that it doesn't always nul terminate the dst buffer that it's filling. Wine code should avoid the use of strncpy for these reasons, and instead use lstrcpynA/W or memcpy."
On 4/26/05, Jeff Latimer jeffl@defcen.gov.au wrote:
Thanks for that. I suppose that wrappering memcpy as as strncpy is not a good idea. To save confusion, would a comment in unicode.h to say "don't worry strncpyW is missing by design and that memcpy/lstrcpynA/W should be used instead" be a good precaution?
ChangeSet ID: 17236 CVSROOT: /opt/cvs-commit Module name: wine Changes by: julliard@wine.codeweavers.com 2005/04/25 11:23:33
Modified files: include : winbase.h
Log message: Define strncpy to an error to make sure it doesn't creep back in.
Patch: http://cvs.winehq.org/patch.py?id=17236
Old revision New revision Changes Path 1.229 1.230 +4 -0 wine/include/winbase.h
Index: wine/include/winbase.h diff -u -p wine/include/winbase.h:1.229 wine/include/winbase.h:1.230 --- wine/include/winbase.h:1.229 Tue Apr 26 14:41:32 2005 +++ wine/include/winbase.h Tue Apr 26 14:41:32 2005 @@ -2065,6 +2065,10 @@ extern inline LPSTR WINAPI lstrcatA( LPS return strcat( dst, src ); }
+/* strncpy doesn't do what you think, don't use it */ +#undef strncpy +#define strncpy(d,s,n) error do_not_use_strncpy_use_lstrcpynA_or_memcpy_instead + #endif /* !defined(WINE_NO_INLINE_STRING) && defined(__WINESRC__) */
#define lstrcat WINELIB_NAME_AW(lstrcat)
-
James Hawkins -
Jeff Latimer