Is there a way to know the memory usage of a function's body?

[lol]

It's all in the title

thx

 

[Mark A. Odell]

It's all in the title

How unconvenient for us. To answer your question, no. There is no sizeof
for a function that would return the actual amount of memory used by the
function. You'll have to look at your linker's map file for this
information.

 

[lol]

ok, thanks

How unconvenient for us. To answer your question, no. There is no sizeof
for a function that would return the actual amount of memory used by the
function. You'll have to look at your linker's map file for this
information.

 

[Richard Thomas Harrison]

Try this in your code.

#define END_OF_FUNC(x) void x##_end(void) { }
#define END_OF_STATIC_FUNC(x) static void x##_end(void) { }
#define FUNC_LENGTH(x) ((long)x##_end - (long)x)

....

static int static_func(void) {
/* Code start */
...
/* Code end */
}

END_OF_STATIC_FUNC(static_func);

void func(long arg1, int arg2) {
/* Code start */
...
/* Code end */
}

END_OF_FUNC(func);

....

Then you can use something like...

printf("Length of static_func is: %li\n", FUNC_LENGTH(static_func));
printf("Length of func is: %li\n", FUNC_LENGTH(func));

Richard

 

[Martin Dickopp]

Try this in your code.

#define END_OF_FUNC(x) void x##_end(void) { }
#define END_OF_STATIC_FUNC(x) static void x##_end(void) { }
#define FUNC_LENGTH(x) ((long)x##_end - (long)x)

...

static int static_func(void) {
/* Code start */
...
/* Code end */
}

END_OF_STATIC_FUNC(static_func);

void func(long arg1, int arg2) {
/* Code start */
...
/* Code end */
}

END_OF_FUNC(func);

...

Then you can use something like...

printf("Length of static_func is: %li\n", FUNC_LENGTH(static_func));
printf("Length of func is: %li\n", FUNC_LENGTH(func));

The result of a conversion of a pointer to `long' is implementation-
defined, or even causes undefined behavior if the result cannot be
represented in `long'.

That aside, the implementation is not even guaranteed to order the
functions in memory in the same way as they are ordered in the source
code.

Martin

 

[Christian Bau]

The result of a conversion of a pointer to `long' is implementation-
defined, or even causes undefined behavior if the result cannot be
represented in `long'.

That aside, the implementation is not even guaranteed to order the
functions in memory in the same way as they are ordered in the source
code.

Another problem is that on one quite common machine, assuming that the
functions _are_ ordered in memory in the same order as the source code,
this macro will _always_ produce a value of eight.

 

[Alan Balmer]

That aside, the implementation is not even guaranteed to order the
functions in memory in the same way as they are ordered in the source
code.

In fact, for the entire range of hosted implementations, my guess
would be that this method is more likely to fail than not. On a
segmented architecture, for example, functions may not even go in the
same segment.

That's why we don't discuss such things on comp.lang.c ;-)