Once qualifications are give, how hard it is to take them away, again!
Of course, if one were realising these small inline functions literally as inline code, one would not add a const qualification for a few lines, only to take it away again (with great difficulty).
Thus, one would not write:
static WCHAR s[] = {'h','e','l','l','o',0}; LPCWSTR ps1; /* [1] */ LPWSTR ps2; const WCHAR ch = 'h';
ps1 = s;
ps2 = NULL; do { if (*ps1 == ch) { ps2 = (LPWSTR)(uintptr_t)ps1; /* [2] */ break; } } while (*ps1++);
if (ps2 != NULL) *ps2 = 'y';
... when [1] need only be
LPWSTR;
and [2} need only be
ps2 = ps1;
So there might be some argument for specially declaring these few functions - suitably commented - as taking unqualified string parameters. (The problem with constifying both input and output pointers is that one might wish to use the returned pointer to modify the input string.)
However, now that the ANSI/ISO people have given use intptr_t and uintptr_t (in C99), I don't see what is wrong with, in effect, replacing
ret = (WCHAR *)str;
with
ret = (WCHAR *)(uintptr_t)str;
To avoid touching Wine's configuration files (to add [u]intptr_t for non-C99 systems) the intermediate cast might be have been (unsigned long). Maybe, (size_t) would have worked, and been more indicative of use(?) "unsigned long" should have met the needs of the platforms for which we cater. The spoiler, apparently, is that it won't work with Win64 type definitions. Though, I don't know the details.
Anyway, I shall look at fixing the straightforward cast-qual violations, first, and revisit the controversial issues until the end.
-- Andy.