S
sumedh.....
it compiles and runs properly.
it compiles and runs properly.
I
Ian Collins
*Please don't quote signatures.*
Then either get a better compiler, or turn up the warnings.
K
Keith Thompson
Ian Collins said:
Quite possibly it does; gcc accepts 'sizeof(main)' (as an extension)
by default.
To the original poster: if you invoke gc with "-std=c99 -pedantic", it
will complain about several problems in your program. If you replace
"-std=99" with "-ansi", it will also complain about the "//" comments
(actually it will completely fail to recognize them and complain about
syntax errors).
Using "//" comments in Usenet postings is usually a bad idea; wrapping
of long lines can easily introduce syntax errors. And you've
neglected the #include directives for <stdio.h> (needed for printf)
and <stdlib.h> (needed for system). And you attempt to use the "%d"
format for arguments of type size_t and of pointer types.
Here's a *nearly* correct version of your program:
#include <stdio.h>
#include <stdlib.h>
typedef int (*Fn)(void);
int main( void ) {
Fn fn = main;
printf("%d\n", (int)sizeof(fn));
printf("%d\n", (int)sizeof(&fn));
printf("%d\n", (int)sizeof(&main));
/* printf("%d\n", (int)sizeof(main)); */
printf("%p %p\n", (void*)fn, (void*)&fn);
printf("%p %p\n", (void*)main, (void*)&main);
return 0;
}
I wrote "nearly" because the casts on the last two printf statements
are actually illegal. There is no portable way to print the value of
a pointer-to-function (other than by decomposing it into a sequence of
bytes). Allowing conversion to void* is a common extension -- more
common, I think, than allowing sizeof to be applied to functions.
P
pete
Ian said:
.... and or make sure that the compiler
is configured as an ANSI C compiler.
I
Ian Collins
That's one thing that has puzzled me for a long time, why would anyoneKeith said:
want to apply sizeof to a function? Even more puzzling considering gcc
evaluates it as 1 when they do.
R
Richard Heathfield
Ian Collins said:
Well, if we stop thinking C and start thinking raw machine for a minute,
it's not difficult to imagine why it might be useful to know how big a
function is - given that information, we could replace some or all of
the function with inline machine code at runtime, presumably only under
certain runtime conditions (because otherwise, why bother?).
Well, if we stop thinking C and start thinking raw machine for a minute,
it's not difficult to imagine why it might be useful to know how big a
function is - given that information, we could replace some or all of
the function with inline machine code at runtime, presumably only under
certain runtime conditions (because otherwise, why bother?).
I
Ian Collins
Fair enough, but what's the point if the result of the expression isRichard said:
always 1?
I
Ian Collins
Even for an extern function!Ian said:
H
Harald van =?UTF-8?B?RMSzaw==?=
Ian said:
gcc makes sizeof(void) and sizeof(func) 1 so that you can do pointer
arithmetic on void and function pointers as if they were char pointers. In
standard C, a conversion to char * is required for this:
/* non-standard */
void *p = malloc(12);
/* NULL check omitted */
int *i = p + 4;
long *l = p + 8;
versus
/* standard */
void *p = malloc(12);
/* NULL check omitted */
int *i = (int *) ((char *) p + 4);
long *l = (long *) ((char *) p + 8);
I don't particularly see the need for this, especially for function
pointers, but apparently others did.
R
Richard Heathfield
Ian Collins said:
Perhaps gcc is just very, very, very good at optimisation?
Perhaps gcc is just very, very, very good at optimisation?
A
Army1987
The problem is when it has to optimize more than 256 functionsIan Collins said:
Perhaps gcc is just very, very, very good at optimisation?
that well.
P
pete
Richard Heathfield wrote:
I don't think it is useful.
The function with the size in question,
might work by calling other functions.
If the sizeof the function doesn't include those helper functions
then it doesn't have the information that you need.
If the sizeof the function does include those helper functions,
you don't know how many of those helper functions
are being used by other functions,
which means that if you delete one function that calls them,
there may still be other functions
that call some of the same helper functions and
your calculations of how much space can be saved
by deleting the function in question, will be wrong.
I don't think it is useful.
The function with the size in question,
might work by calling other functions.
If the sizeof the function doesn't include those helper functions
then it doesn't have the information that you need.
If the sizeof the function does include those helper functions,
you don't know how many of those helper functions
are being used by other functions,
which means that if you delete one function that calls them,
there may still be other functions
that call some of the same helper functions and
your calculations of how much space can be saved
by deleting the function in question, will be wrong.
R
Richard Heathfield
pete said:
Well, it isn't all /that/ useful.
Wouldn't matter, if you were replacing it at runtime with inline
assembly language.
You lost me. Why would you need that info? All you're doing is an
overlay, not a complete runtime code optimisation.
Well, it isn't all /that/ useful.
Wouldn't matter, if you were replacing it at runtime with inline
assembly language.
You lost me. Why would you need that info? All you're doing is an
overlay, not a complete runtime code optimisation.
I
Ian Collins
And psychic, considering the sizeof an extern function is also 1!Richard said:Ian Collins said:
Perhaps gcc is just very, very, very good at optimisation?
P
pete
Richard said:
I guess I don't understand the usage.
I look at compiler listing files
when I want to see the memory usage for the program instructions.