Apache OpenOffice (AOO) Bugzilla – Issue 100502
oox: gcc finds operations && || ambigous
Last modified: 2009-09-22 09:09:47 UTC
In oox/source/docprop/docprophandler.cxx there is... if ( m_nInBlock == 2 || m_nInBlock == 3 && m_nType ) I want to confirm that the operator precedence is intentional, i.e. we mean as version1 patch attached, and not that we instead meant like version2
Created attachment 61137 [details] version 1, keeps current behaviour
Created attachment 61139 [details] version 2, there's a chance that this is what was meant
dr->mav: I assume the second option is what you meant, right? I will add this to my CWS.
grabbing issue...
fixed in CWS DEV300/dr68 (OOo 3.2)
mav->dr: No, the source code is so as it was intended. The second patch will break the implementation. If you would like to introduce the patch, please use the first one that does not change the behavior. PS: I assume that the change is done because of the new warning of the gcc compiler. Although we have to support it, from my point of view the warning is more than just useless.
Changing the title
changed implementation accordingly, thanks for your feedback.
FWIW, while in this case the implementation was correct, in about 40 out of 45 previous cases the precedence rules were not what was intended so it would appear to be a quite useful warning. Though as we're down to the small subset of gray ones where it the code is neither obviously wrong or obvious right I guess the ratio will change
Mikhail, I also thought at first that these kinds of warnings are superfluous. But I learned and saw that they revealed some bugs in other places, where (different to your case) the code was not working as the sloppy developer wanted. So it makes a lot of sense to set braces even if they are not necessary. It also makes the code easier to read and understand, and that's a good thing also.
If the warning has helped to find and fix around 40 bugs from 45 suspicious cases, it indeed makes sense. I did not pretend to be error prove in case of logical expressions. It is probably a matter of taste, for me additional brackets, especially brackets in brackets, make in most cases big expressions less readable.
verified in CWS
closed