James Hawkins wrote:
Hi,
This patch is based on a patch written by Stefan Huehner in 2005. With the -Wcast-qual warning turned on, these five wine-internal unicode functions produce over 1400 warnings:
strchrW, strrchrW, strpbrkW, memchrW, memrchrW
This patch gets rid of those warnings. Any ideas about this guys?
[...]
I think this sort of double casting is the way to go. I would just mention a couple of possible caveats. When I discussed this with Alexandre, some time back, he expressed a concern that he didn't want to see this kind of thing proliferate throughout the code base, so I would suggest that this type of fix should be confined to a small number of very specific functions (typically string functions that take in a const string and return a non-const version: there are others like this elsewhere) and be applied inline, rather than with a macro, so as not to put temptation in anyone's way. The second point I would make is that - and I haven't tested this on gcc - if, say, ULONG_PTR is bigger than the size of a WCHAR * on any system we support, the compiler might warn of a possible truncation loss when the outer (WCHAR *) cast converts back to a pointer, which would be rather unfortunate. :)
I presume ULONG_PTR is good for both Win32 and Win64.
-- Andy.
On Saturday 07 October 2006 10:27, Andrew Talbot wrote:
I think this sort of double casting is the way to go. I would just mention
An alternative would be to make the return value const. Although these functions are wide character equivalents of POSIX functions they are Wine internal functions, so we can change their prototypes. But yes, the difference may confuse programmers.
This will introduce cast-qual warnings but by far not as many as it eliminates. Those can be solved by creating a copy of the buffer or by using a local wrapper that double-casts the constness away.
-Hans
Hans Leidekker wrote:
An alternative would be to make the return value const.
The problem with that is that sometimes these functions are called with writeable strings, and the return value is used to modify the original string, something like:
static WCHAR stringW = {'s','t','r','i','n','g','\',0}; WCHAR *p;
p = strchrW(stringW, '\'); *p = {'\n'};
Another solution might be, where appropriate - such as in strchrW() - to replace certain functions with versions that, instead of returning a pointer, returns an offset from the start of the string using a signed integer type, i.e., in this case, declared as something like:
INT strchrofsW(const WCHAR *str, WCHAR ch);
This could return a negative value (such as -1) for the "not found" case, since ch could be at offset zero.
I think that would work for const and non-const strings, alike.
-- Andy.
On Saturday 07 October 2006 12:03, Andrew Talbot wrote:
The problem with that is that sometimes these functions are called with writeable strings, and the return value is used to modify the original
Yes, that's why I suggested making a copy or writing a local wrapper that removes the constness.
Another solution might be, where appropriate - such as in strchrW() - to replace certain functions with versions that, instead of returning a pointer, returns an offset from the start of the string using a signed integer type, i.e., in this case, declared as something like:
Rewriting the code to avoid the problematic functions is a third option. I find the approach that solves the constness issues locally better than the one that casts the constness away in the global functions. The reason is that there may be better options available locally than to simply cast the constness away.
-Hans
-
Andrew Talbot -
Hans Leidekker