Re: mshtml: Set outgoing pass-by-address variable in an error case case within confirm_safety_load.
Hi Gerald, On 03/07/12 23:35, Gerald Pfeifer wrote:
I noticed we return in this case, without initializing this variable. Visual inspection indicates we do not seem to access the variable in this error case, but a) better safe than sorry, and b) GCC 4.8 currently warns about it.
Not sure URLPOLICY_DISALLOW is the best return value, open for better alternatives.
I generally don't think this patch makes things any better (or worse). If we return an error, the caller should not expect this value to be sane. What's the GCC 4.8 warning? Jacek
On Thu, 8 Mar 2012, Jacek Caban wrote:
I noticed we return in this case, without initializing this variable. Visual inspection indicates we do not seem to access the variable in this error case, but a) better safe than sorry, and b) GCC 4.8 currently warns about it. I generally don't think this patch makes things any better (or worse). If we return an error, the caller should not expect this value to be sane. What's the GCC 4.8 warning?
secmgr.c:230:1: warning: 'policy' may be used uninitialized in this function [-Wmaybe-uninitialized] An alternative to silence this would be initializing policy to some default value. Would that be preferrable? Gerald
On 03/08/12 21:55, Gerald Pfeifer wrote:
On Thu, 8 Mar 2012, Jacek Caban wrote:
I noticed we return in this case, without initializing this variable. Visual inspection indicates we do not seem to access the variable in this error case, but a) better safe than sorry, and b) GCC 4.8 currently warns about it. I generally don't think this patch makes things any better (or worse). If we return an error, the caller should not expect this value to be sane. What's the GCC 4.8 warning? secmgr.c:230:1: warning: 'policy' may be used uninitialized in this function [-Wmaybe-uninitialized]
An alternative to silence this would be initializing policy to some default value. Would that be preferrable?
It's clearly a false positive. If we return an error in confirm_safety_load, we'll never execute the line from warning. Since GCC 4.8 is in an early development stage, I don't think we should change the code to hide its buggy warnings. It would be much better to see it fixed on GCC side, so GCC bug report would be more appropriate at this point IMO. Cheers, Jacek
On Thu, 8 Mar 2012, Gerald Pfeifer wrote:
I noticed we return in this case, without initializing this variable. Visual inspection indicates we do not seem to access the variable in this error case, but a) better safe than sorry, and b) GCC 4.8 currently warns about it. I generally don't think this patch makes things any better (or worse). If we return an error, the caller should not expect this value to be sane. What's the GCC 4.8 warning? secmgr.c:230:1: warning: 'policy' may be used uninitialized in this function [-Wmaybe-uninitialized]
An alternative to silence this would be initializing policy to some default value. Would that be preferrable?
I did not see a response to this, but it seems Francois ran into the same in the meantime and addressed it similarly, so this can be closed: http://www.winehq.org/pipermail/wine-cvs/2012-July/088865.html (http://www.winehq.org/pipermail/wine-patches/2012-March/112089.html was my original submission.) Gerald
On 07/17/12 22:51, Gerald Pfeifer wrote:
On Thu, 8 Mar 2012, Gerald Pfeifer wrote:
I noticed we return in this case, without initializing this variable. Visual inspection indicates we do not seem to access the variable in this error case, but a) better safe than sorry, and b) GCC 4.8 currently warns about it. I generally don't think this patch makes things any better (or worse). If we return an error, the caller should not expect this value to be sane. What's the GCC 4.8 warning? secmgr.c:230:1: warning: 'policy' may be used uninitialized in this function [-Wmaybe-uninitialized]
An alternative to silence this would be initializing policy to some default value. Would that be preferrable? I did not see a response to this, but it seems Francois ran into the same in the meantime and addressed it similarly, so this can be closed:
http://www.winehq.org/pipermail/wine-cvs/2012-July/088865.html
(http://www.winehq.org/pipermail/wine-patches/2012-March/112089.html was my original submission.)
See: http://www.winehq.org/pipermail/wine-devel/2012-July/096177.html Jacek
participants (2)
-
Gerald Pfeifer -
Jacek Caban