I'm sorry Taras, i messed up addressing this message to list, so you'll probably get this message twice.
2008/10/21 Taras Glek <[EMAIL PROTECTED]>: > Piotr Rak wrote: >> >> Hi all, >> >> I'm trying compute CK/MOOD metrics for my project as homework using >> dehydra/treehydra. >> Everything works better than I expected, beside one assertion failure. >> >> dehydra_ast.c:29: Assertion failed:length < dehydra_getArrayLength >> (this, this->destArray) >> > > Such low expectations :) > > Dehydra has a few asserts like this for making sure that it's processing > code as expected. I haven't spent the time to implement C++0x features as I > have no interest in that, thus the assert was triggers when a > pointer-to-member constant ptrmem_cst(new ast node added in C++0x as far as > I can tell) is returned. Dehydra isn't aware of that ast node type being > something important, so it skips it and the return expression code asserts > with "no, i gotta have something here". > > One "fix" would be to not worry about that detail and convert the assert to > if (!assert cond) return NULL. Another would be to implement C++0x features > like this as you hit them. > > I'm attaching both alternatives. First one disables the assert and the > second one handles the new node type. Choose one that suits your needs best, > I didn't look at the code that caused that triggered the assert, so i'm not > 100% sure that the new-ast-node patch is correct. > ptrmem_cst.diff patch caused ice for me in other file, by simply moving case label to place where other *_CST are handled fixed the issue. I have attached version that worked for me, however my change was rather lucky bet, than understanding what is going on.:) I have not tested 0x.diff yet, but i will try to do it tomorrow. >> I have attached an example file with preprocessed sources causing this >> problem. >> Please note, that my project is written using c++0x dialect features >> and requires -std=c++0x flag to compile. >> It seems to be related to decltype keyword, but I wasn't able prove >> that it is indeed culprit. >> > > To summarize, c++0x isn't supported, but I'd welcome any contributions in > that area. Sounds fair enough:) I will try add some support when I will get more familiar with dehydra, and gcc internals... And it seems, that I will spend more time with *hydras in near future, becouse this is the tool I was looking for. >> >> I would be also interested in dehydra-gcc patches for newer gcc (4.4) >> versions, if any exist. >> > > Once GCC 4.4 is out, I'll make a new patchset. > > Cheers, > Taras > > PS. I'd be interested to hear how far you get on code metrics with Dehydra. > It's an area I haven't had a chance to explore. > I'm not doing anything fancy here yet. Dehydra gives me most of data I needed so far, and treehydra will probably provide rest soon (ie. more accurate data about object field references and simple data about branches). I'll post results once I'll get something interesting and working hopefully :) Great thanks! Piotr
_______________________________________________ dev-static-analysis mailing list [email protected] https://lists.mozilla.org/listinfo/dev-static-analysis
