ElectronVector
Return values are counted as globals
As an example, I have the following as the total contents of a file called sample1.c
#include <stdint.h>
uint8_t ctof_truncates(uint8_t c)
{ //simple version, rounds fractions down
uint8_t i;
if (c < 255 / 9)
{
i = c * 9;
i /= 5;
}
else
{
i = c / 5;
i *= 9;
}
i += 32;
return i;
}
for which the command ravioli -f sample1.c produces the output
-------------------------------------------------------------------------------
Globals
-------------------------------------------------------------------------------
sample1.c:21 i
-------------------------------------------------------------------------------
Functions complexity
-------------------------------------------------------------------------------
sample1.c:4
ctof_truncates
but i is declared within the scope of the function, and the line which ravioli complains about is the return i statement.
I have found that it does not count i as global if that line is changed to return (i); but this is more of a hint than a workaround since ravioli is supposed to be used with existing code.
Maybe this problem did not exist in earlier versions because your readme file shows FreeRTOS\tasks.c with zero globals but ravioli 0.3.0 shows 64 globals, many of which are xReturn or break
It's the same for me. Could be something wrong with the find_globals(code) function. My python understanding is very limited. At a glance, maybe there is something wrong with the expression
# Remove anything between brackets.
code = re.sub(r'{[^}]*}', '{}', code, flags=re.DOTALL)
Hello!
It turns out the the way ravioli counts globals is quite naive -- and likely to be quite buggy -- and also isn't correct for the way KSF is defined.
What it needs to count are global usages not merely global definitions. This is a bit more complicated problem.
Global definitions are not as useful because they could be anywhere, and ravioli as currently implemented is going to miss anything not defined in the file that it's processing.
I'm actually currently doing a major rework to global counting to correctly count usages, so I'm not planning to specifically address this particular issue. Once I'm done with the rework everything should work more correctly (and better) but there are definitely going to be some edge cases to handle.
