Function counting script

[Segin]

As my small contribution, attached is a small shell script that, 
unmodified, finds out how many times certain functions are called in a 
given sample of files. The default functions are 'malloc', 'realloc', 
and 'free', and the sample files are all files ending in .c in the 
current directory. It even prints out the result in a neat manner on 
ANSI colourized terminals.

The script is very flexible, and easy to modify.

Current version is 256bytes long.

[Joris Huizer]

Segin wrote:
> As my small contribution, attached is a small shell script that, 
> unmodified, finds out how many times certain functions are called in a 
> given sample of files. The default functions are 'malloc', 'realloc', 
> and 'free', and the sample files are all files ending in .c in the 
> current directory. It even prints out the result in a neat manner on 
> ANSI colourized terminals.
>
> The script is very flexible, and easy to modify.
>
> Current version is 256bytes long.
>
> ------------------------------------------------------------------------

Hmmm, I'm affraid this isn't telling much, consider:

int main()
{
   int i;
   char *ptr;
   for (i = 0; i < 10; i++)
     ptr = malloc(20);
   free(ptr);
   return 0;
}

you're script will report one 'malloc' and one 'free', but ten times a 
'malloc' is executed and only one 'free' ... :-/

[Segin]

It's not a C interpeter, it's literally a frint end of sorts to grep. 
There's only one textual occurence of malloc() in the code, so it only 
returns one.

Think before you speak.

P.S. I'll add a C interpeter when there becomes a need for one.

Joris Huizer wrote:
> Segin wrote:
> > As my small contribution, attached is a small shell script that, 
> > unmodified, finds out how many times certain functions are called in 
> > a given sample of files. The default functions are 'malloc', 
> > 'realloc', and 'free', and the sample files are all files ending in 
> > .c in the current directory. It even prints out the result in a neat 
> > manner on ANSI colourized terminals.
> >
> > The script is very flexible, and easy to modify.
> >
> > Current version is 256bytes long.
> >
> > ------------------------------------------------------------------------
>
> Hmmm, I'm affraid this isn't telling much, consider:
>
> int main()
> {
> int i;
> char *ptr;
> for (i = 0; i < 10; i++)
> ptr = malloc(20);
> free(ptr);
> return 0;
> }
>
> you're script will report one 'malloc' and one 'free', but ten times a 
> 'malloc' is executed and only one 'free' ... :-/

[Joris Huizer]

Segin wrote:
> It's not a C interpeter, it's literally a frint end of sorts to grep. 
> There's only one textual occurence of malloc() in the code, so it only 
> returns one.
>
> Think before you speak.
>
> P.S. I'll add a C interpeter when there becomes a need for one.

It was my impression that the goal was to find leaks by counting 
allocating and freeing of memory;
My example was about that: the counts do not have to indicate correct 
usage of malloc()/free()
Sorry if this was an incorrect assumption

regards,

Joris

[Jim White]

Joris Huizer wrote:
> Segin wrote:
> > It's not a C interpeter, it's literally a frint end of sorts to grep. 
> > There's only one textual occurence of malloc() in the code, so it only 
> > returns one.
> >
> > Think before you speak.
> >
> > P.S. I'll add a C interpeter when there becomes a need for one.
>
> It was my impression that the goal was to find leaks by counting 
> allocating and freeing of memory;
> My example was about that: the counts do not have to indicate correct 
> usage of malloc()/free()
> Sorry if this was an incorrect assumption

Right.  And by reading the code that is doing alloc/free you can 
determine if they are balanaced.  But first you have to *find* where 
those calls are made.

Jim

[Segin]

Jim White wrote:
> Joris Huizer wrote:
> > Segin wrote:
> > > It's not a C interpeter, it's literally a frint end of sorts to 
> > > grep. There's only one textual occurence of malloc() in the code, so 
> > > it only returns one.
> > >
> > > Think before you speak.
> > >
> > > P.S. I'll add a C interpeter when there becomes a need for one.
> >
> > It was my impression that the goal was to find leaks by counting 
> > allocating and freeing of memory;
> > My example was about that: the counts do not have to indicate correct 
> > usage of malloc()/free()
> > Sorry if this was an incorrect assumption
>
> Right. And by reading the code that is doing alloc/free you can 
> determine if they are balanaced. But first you have to *find* where 
> those calls are made.
>
> Jim

This gives me an idea: I can add a command line flag to determine how to 
invoke grep (e.g. just a count, or a count plus occurences by line)

[Segin]

That's ok, I failed to document that myself. In truth, it would 
truthfully be inpossible to find run-time memory leaks like that using a 
script because of a potential unknown variable in a for loop which is 
derived from an argument or return from another function.

I will try to add code for detecting contant for loops at one point.

Also, the script is designed to be edited and whatever function you want 
to look for inserted into the code.

Joris Huizer wrote:
> Segin wrote:
> > It's not a C interpeter, it's literally a frint end of sorts to grep. 
> > There's only one textual occurence of malloc() in the code, so it 
> > only returns one.
> >
> > Think before you speak.
> >
> > P.S. I'll add a C interpeter when there becomes a need for one.
>
> It was my impression that the goal was to find leaks by counting 
> allocating and freeing of memory;
> My example was about that: the counts do not have to indicate correct 
> usage of malloc()/free()
> Sorry if this was an incorrect assumption
>
> regards,
>
> Joris