Wide-string Functions: Double Casting

Andrew Talbot Andrew.Talbot at talbotville.com
Sat Aug 12 13:27:02 CDT 2006


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.





More information about the wine-devel mailing list