On 8 Oct 2003, Daniel Marmier wrote:
Fixed warnings with gcc option "-Wwrite-strings".
BTW, how far away are we from always compiling with -Wwrite-strings?
On Wed, 2003-10-08 at 21:58, Dimitrie O. Paun wrote:
BTW, how far away are we from always compiling with -Wwrite-strings?
Well, much warnings are gone, but we're still some patches (and days) away, because I started with the most obvious ones, and I am now running into the less obvious.
Most of the remaining are about code that deals whith something external (e.g. WIN32 function, commctl.h structure).
The brute force approach would be to always use variable strings in those cases. However there are a number of cases where we know that the string will be treated as constant. I do not like brute force, because: - it is useless in these cases - it makes the code less readable - it makes the data more writable ... - it will affect performance - I hear them come, furious, shouting that my patches are bloatware
There has to be a better solution. Perhaps something like:
#define FAKE_LPSTR(s) ((LPSTR)(ptrdiff_t)(s))
WriteSpool16( physDev->job.hJob, FAKE_LPSTR(buf), strlen(buf) );
Where the intermediate cast to ptrdiff_t serves to shut-up gcc's -Wcast-qual (which might be my one of my next candidates ...)
Or perhaps something really better ...
Comments, ideas, suggestions?
Best Regards,
Daniel Marmier
Daniel Marmier d.marmier@bluewin.ch writes:
There has to be a better solution. Perhaps something like:
#define FAKE_LPSTR(s) ((LPSTR)(ptrdiff_t)(s))
WriteSpool16( physDev->job.hJob, FAKE_LPSTR(buf), strlen(buf) );
Where the intermediate cast to ptrdiff_t serves to shut-up gcc's -Wcast-qual (which might be my one of my next candidates ...)
Or perhaps something really better ...
Comments, ideas, suggestions?
In some cases parameters to API functions are not declared const even though they really are const; some of these could be fixed. Notably, all the 16-bit ones can be freely changed since no external code depends on them. Some 32-bit ones can probably be changed too, like all the undocumented ones. Not sure how much this helps.
In cases where the official prototype is broken but we can't fix it, I think a cast is better than creating a writable string. Of course this means making sure that the string really isn't modified by the function.
Alexandre Julliard wrote:
In some cases parameters to API functions are not declared const even though they really are const; some of these could be fixed. Notably, all the 16-bit ones can be freely changed since no external code depends on them. Some 32-bit ones can probably be changed too, like all the undocumented ones. Not sure how much this helps.
In cases where the official prototype is broken but we can't fix it, I think a cast is better than creating a writable string. Of course this means making sure that the string really isn't modified by the function.
I have also stumbled across a case where the official declaration is a constant string, but Windows modifies the string anyway, at least temporarily. The string was changed back before the function returned.
In particular, BuildCommDCB's official declaration is:
BOOL BuildCommDCB(LPCSTR lpDef, LPDCB lpDCB)
However, if you pass a true constant string for lpDef in Windows 95 it will crash because Windows tries to write to it.
This is why in the conformance test I wrote for BuildCommDCB I did not use constant strings. When I did, the test would crash under Windows 95.
I am not sure if this has any other implications for wine, but it is an interesting fact none the less. Maybe if native DLL's are used which may have similar problems, problems could occur if wine used a true constant string.
Kevin
-
Alexandre Julliard -
Daniel Marmier -
Dimitrie O. Paun -
Kevin Groeneveld