Hi timovjl, thank you for your reply.
After reading the
PellesC 2.5 to 2.6 change note and the
MSDN, I understand that the objective in mapping _stprintf to snprintf when _UNICODE is not defined is to have it compatible wit the _UNICODE variant where it is mapped to swprintf.
Unfortunately, swprintf has a different signature for Windows and Windows CE. See wchar.h (from Pelles C 6.0):
#ifndef _WINCE
_CRTCHK(printf,3,4) int __cdecl swprintf(wchar_t * restrict, size_t, const wchar_t * restrict, ...);
//...
#else /* _WINCE */
int __cdecl swprintf(wchar_t *, const wchar_t *, ...); /* WinCE */
//...
#endif /* _WINCE */
I.e. swprintf is lacking the size_t parameter for WinCE (see also
here).
So while
#define _stprintf snprintf /* 03-07-27: sprintf -> snprintf */
improves consistency for Win32, it reduces consistency for WinCE applications.
Since _stprintf is Microsoft specific and Microsoft sticks to
#define _stprintf sprintf
I would prefer PellesC to go the same way.
Note: I came across this, because my use case is to compile my applications from the same source for Win32 (without _UNICODE) and WinCE (with _UNICODE) and I need a generic version for sprintf. If I had needed a generic version of snprintf, I would have chosen _sntprintf. So now I am limited in my choice which I don't like
. I guess I will change my code to use _sntprintf instead of _stprintf to work around that problem.
Nevertheless this is only a small issue in an otherwise great Compiler. Pelle: thank you!
