hi Nathaniel cc Dan,

thanks a lot for clearing up completely the entire story. I'm afraid that one or two cycles ago of our conversation i did a simple reply instead of a reply-all and the bioc-devel list wasn't included anymore in the recipients of these emails.

since what you say below sounds like a relevant piece of information for anyone working with C code i'm cc'ing the bioc-devel list again.

cheers,
robert.

On 6/16/14 11:15 PM, Nathaniel Hayden wrote:
Hi, Robert. You are correct. zin2 and petty failed to emit warnings for the problematic code. After some digging we discovered that for gcc, any optimization level above 0 prevents emission of the -Wsequence-point warning in this case. But the optimizations must stay for production code.

As a follow-up to the recommendations before about flags to use during package development, we have added content to the Package Guidelines page on our website: http://www.bioconductor.org/developers/package-guidelines/#c-code

The failure of some build machines to emit the warning under production conditions underscores the importance of the original recommendation to enable as many warnings as possible during development.

Thanks for bringing it up!
Nate

On Mon 16 Jun 2014 07:42:36 AM PDT, Robert Castelo wrote:

hi Nathaniel,

On 06/14/2014 01:01 AM, Nathaniel Hayden wrote:

Hi, Robert. You're welcome.

It sounds like something isn't happening, but you think it
should. Could you be more precise about what you expect to happen (the
conditions that *should* lead to the warning, but do not)? There are
lots of variables floating around:
- devel or release? (I see similar commits to devel and release so
unclear which I should look at; current devel version looks like it
fails before it has a chance to give the warning.)


yes, this was an unrelated error, which actually Dan warned me about
and for which i sent a fix yesterday. the situation i was describing
was occurring in both, devel and release, but both are fixed by now.


- it sounds like you're talking about a Mavericks machine in the Bioc
build system; can you confirm which one?

Both the devel and release Mavericks build machines use clang, and
both linux machines (zin1/zin2) use gcc with -Wall.


so, for instance, the release version from VariantFiltering 1.0.1 was
giving these warnings i was talking about:

Found the following significant warnings:
methods-WeightMatrix.c:256:19: warning: unsequenced modification and
access to 'q' [-Wunsequenced]
methods-WeightMatrix.c:638:17: warning: unsequenced modification and
access to 'q' [-Wunsequenced]

*only* in the R CMD check from 'morelia' and not from 'petty' or
'zin2', while all three machines in principle have the -Wall option
activated.

currently, because i submitted the fix, version 1.0.2 does not give
these warnings anymore. however, i have just committed a new version
to de release branch, 1.0.3, that has this problem back in line 256:

while ((*q++=tolower(*q)));

and should recreate the odd situation i saw, that only 'morelia' warns
about this line, but not 'petty' or 'zin2'.


thanks!
robert.




Thanks,
Nate

On 06/13/2014 12:54 AM, Robert Castelo wrote:

hi Nathaniel,

thanks for the very clear examples. after all, probably it is just my
package which may have this problem. one further question below..

On 06/12/2014 07:12 PM, Nathaniel Hayden wrote:

Hi, Robert. C++ is my area so I can't speak as knowledgeably about C,

[...]

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)


the strange things is that the only machine at the building pipeline
of BioC that warned about this in my package was the one running Mac
OSX Mavericks with gcc 4.8.2 and not also the Linux zin2 which is
running gcc 4.6.3

you can see it if the 1.0.1 version of VariantFiltering is still at
the check report.

anyway, i'll use those options during development and that should
avoid me this kind of problems in the future.

thanks!
robert.






_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel

Reply via email to