Hi, Robert. C++ is my area so I can't speak as knowledgeably about C,
but in this case I believe the cause is the same. I think the reason it
feels like the postincrement evaluation order has been changed without
warning is the code relied on 'undefined behavior'.
Often, in C-based languages 'undefined behavior' categorizes things a
standardization committee identified as something that, for performance
reasons, made more sense to rely on programmers to program around.
In the unsequenced modification and access case, according to the
standard the compiler is free to evaluate the subexpressions in *any
order*, the idea being the compiler will identify the most performant order.
Consider:
a[i] = i++;
This does three things
1) get array element a[i]
2) increment i
3) assign 2) to 1)
The only guarantee is 3) happens after 1) and 2), but 1) and 2) can
happen in any order.
As you correctly identified, the way to avoid undefined behavior is to
break the modification and access into separate full expressions. The
simplest way to make a full expression is to put a semicolon after it!
A related place this comes up is in evaluating arguments for a function
call.
Consider:
f(g(), h());
The only guarantee is that g() and h() will be evaluated before f is
called. But what if g() and h() each have side effects on shared data?
It's up to you to tell the compiler, for example, to first do g(),
*then* do h() with:
int gres = g();
int hres = h();
f(gres, hres);
I confirm that using your test file gcc 4.6.3 indeed warns about
unsequenced shenanigans with -Wall 'warning: operation on ‘p’ may be
undefined [-Wsequence-point]'. I would add it's also a good idea during
the development cycle to use -Wextra and -pedantic flags. (You can read
about them here: http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html)
On Thu 12 Jun 2014 08:45:39 AM PDT, Robert Castelo wrote:
hi Dan,
On 06/12/2014 04:28 PM, Dan Tenenbaum wrote:
[...]
Thanks for figuring this out and sharing it.
Note that on the build machines, the compiler used on Mavericks is
not gcc but clang.
More info here:
http://www.bioconductor.org/checkResults/2.14/bioc-LATEST/morelia-NodeInfo.html
http://www.bioconductor.org/checkResults/3.0/bioc-LATEST/oaxaca-NodeInfo.html
ok, i see, one question, in the build reports at the BioC site the R
CMD check warns about this kind of problematic post-increment
suggesting this is the result of using the option -Wunsequenced
i've been trying to install and check my package using that option but
i cannot find the way to do it.
could you tell me how have you set up the R CMD INSTALL or R CMD CHECK
command in the building pipeline so that the compiler warns about this
problem?
is actually -Wunsequenced a specific option of this 'clang' compiler?
thanks!
robert.
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
