Re: d3dx9_36: Silence an uninitialized compiler warning (GCC 8).
There is actually no usage of uninitialized variable there, though it is probably not exactly straightforward for compiler to guess. Why it does not complain that 'cdesc[index]' may be used uninitialized while it is handled the same way? AFAIK GCC 8 is not released yet, maybe this will change before final release? If still to change that, does the attached patch fixes the warning as well (sorry, I don't have gcc 8 in hands to test)? If yes, I would suggest that would be a tiny bit nicer way to silence the warning. On 11/07/2017 01:22 AM, Gerald Pfeifer wrote:
There are more of this in d3dx9_36, but at least this is one down.
Gerald
Signed-off-by: Gerald Pfeifer <gerald(a)pfeifer.com> --- dlls/d3dx9_36/preshader.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/dlls/d3dx9_36/preshader.c b/dlls/d3dx9_36/preshader.c index e3e91c643b..ed22dc4045 100644 --- a/dlls/d3dx9_36/preshader.c +++ b/dlls/d3dx9_36/preshader.c @@ -888,7 +888,7 @@ static HRESULT get_constants_desc(unsigned int *byte_code, struct d3dx_const_tab for (i = 0; i < desc.Constants; ++i) { unsigned int index = out->input_count; - WORD constantinfo_reserved; + WORD constantinfo_reserved = 0;
hc = ID3DXConstantTable_GetConstant(ctab, NULL, i); if (!hc)
2017-11-08 10:33 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>:
There is actually no usage of uninitialized variable there, though it is probably not exactly straightforward for compiler to guess. Why it does not complain that 'cdesc[index]' may be used uninitialized while it is handled the same way? AFAIK GCC 8 is not released yet, maybe this will change before final release?
If still to change that, does the attached patch fixes the warning as well (sorry, I don't have gcc 8 in hands to test)? If yes, I would suggest that would be a tiny bit nicer way to silence the warning.
If that works it would be preferable to me too.
On Wed, 8 Nov 2017, Paul Gofman wrote:
There is actually no usage of uninitialized variable there, though it is probably not exactly straightforward for compiler to guess. Why it does not complain that 'cdesc[index]' may be used uninitialized while it is handled the same way?
Yes, I did not find this really being used uninitialized (and, yes, you're right, it actually does complain about cdesc[index] as well -- those were the other warnings I referred to, where I did not have a fix/workaround yet).
If still to change that, does the attached patch fixes the warning as well (sorry, I don't have gcc 8 in hands to test)? If yes, I would suggest that would be a tiny bit nicer way to silence the warning.
Yes, it does, plus -- unlike my patch -- it also addresses the other warnings, so indeed it's also more effective. On Wed, 8 Nov 2017, Matteo Bruni wrote:
If that works it would be preferable to me too.
Same here. :-) Can we go with your patch, Paul? Thanks, Gerald
On 11/09/2017 11:39 PM, Gerald Pfeifer wrote:
On Wed, 8 Nov 2017, Paul Gofman wrote:
There is actually no usage of uninitialized variable there, though it is probably not exactly straightforward for compiler to guess. Why it does not complain that 'cdesc[index]' may be used uninitialized while it is handled the same way? Yes, I did not find this really being used uninitialized (and, yes, you're right, it actually does complain about cdesc[index] as well -- those were the other warnings I referred to, where I did not have a fix/workaround yet).
I suppose cdesc[index] can be zeroed on error in the same function which fills it, but in my understanding the wined3d style did not approve redundant zero initializations (unless I missed anything here), including auto variables and redundant HEAP_ZERO_MEMORY flag to HeapAlloc(). So what should happen now to the code already there and new patches if gcc 8 starts issuing this warning false positive? Could it be just a bug which will be fixed in gcc maybe?
2017-11-09 23:12 GMT+01:00 Paul Gofman <gofmanp(a)gmail.com>:
On 11/09/2017 11:39 PM, Gerald Pfeifer wrote:
On Wed, 8 Nov 2017, Paul Gofman wrote:
There is actually no usage of uninitialized variable there, though it is probably not exactly straightforward for compiler to guess. Why it does not complain that 'cdesc[index]' may be used uninitialized while it is handled the same way?
Yes, I did not find this really being used uninitialized (and, yes, you're right, it actually does complain about cdesc[index] as well -- those were the other warnings I referred to, where I did not have a fix/workaround yet).
I suppose cdesc[index] can be zeroed on error in the same function which fills it, but in my understanding the wined3d style did not approve redundant zero initializations (unless I missed anything here), including auto variables and redundant HEAP_ZERO_MEMORY flag to HeapAlloc(). So what should happen now to the code already there and new patches if gcc 8 starts issuing this warning false positive? Could it be just a bug which will be fixed in gcc maybe?
If I understood Gerald's email correctly, those other warnings are also fixed by your patch. BTW, could you please send it as a proper patch to wine-patches? It would be helpful :)
participants (3)
-
Gerald Pfeifer -
Matteo Bruni -
Paul Gofman