M
maadhuu
does it make sense to find the size of a function ???
something like sizeof(main) ???
thanking you
ranjan.
something like sizeof(main) ???
thanking you
ranjan.
R
Robert Gamble
maadhuu said:
No, doing so is a constraint violation.
Robert Gamble
W
Walter Roberson
No.
gcc without --pedantic allows it, but the size it returns is 1
(at least for my test cases). With --pedantic, or if I
use a stricter compiler, it complains at compile time.
Remember, there isn't anything you can -do- to a function
pointer, except to store it or call through it (or convert it
to void*). sizeof a function might make sense if you could
index the function object in some way, but you cannot
(not without invoking undefined behaviour.)
If you had hope of using a program to examine the code of
a function, or bash the function or whatnot, then you can
forget about that in standard C -- there's no portable way to do that
[and any non-portable way is a topic for a newsgroup specific to
your operating system.]
E
Emmanuel Delahaye
maadhuu wrote on 04/09/05 :
Why do you need this information ?
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
"It's specified. But anyone who writes code like that should be
transmogrified into earthworms and fed to ducks." -- Chris Dollin CLC
Why do you need this information ?
--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html
"It's specified. But anyone who writes code like that should be
transmogrified into earthworms and fed to ducks." -- Chris Dollin CLC
M
maadhuu
i don't think there is anything wrong in knowing such things , not
necessary that it should be always used somewhere , also why is it a
violation ??
necessary that it should be always used somewhere , also why is it a
violation ??
R
Robert Gamble
Walter said:
Just to clarify: you *can* use sizeof on a function pointer, just not
on the function itself.
Robert Gamble
R
Robert Gamble
Please provide context when posting a followup so we know what you are
responding to.
Agreed, if you don't ask you might never know.
Because the Standard says so.
Robert Gamble
responding to.
Agreed, if you don't ask you might never know.
Because the Standard says so.
Robert Gamble
A
Alexei A. Frounze
maadhuu said:
void myfunc(){/*body of the func whose size you want*/}
void bar(){}
bar-myfunc may tell you the size.
But it *may not* just as well due to optimizations and code reordering. I'd
not rely on this, there's no any guarantee here.
Alex
K
Keith Thompson
Correction: you can't legally convert a function pointer to void*
(though some implementations may allow it).
K
Keith Thompson
Alexei A. Frounze said:
No, the "-" operator is not defined for function pointers.
*If* an implementation allows function pointers to be converted to
char*, then
(char*)bar - (char*)myfunc
might give you something meaningful. But conversion of a function
pointer to char* isn't legal either, though some implementations may
allow it.
K
Keith Thompson
Robert Gamble said:
And why does the Standard say so? Because there's nothing meaningful
you can do with the result. It can be interesting to know how many
bytes a given function occupies, but there's really nothing you can do
with it.
E
Eric Sosman
Robert said:
Robert's answer is correct, but unsatisfactory. The
obvious follow-up is "But *why* does the Standard say so?"
There's no 100% certain answer, because the Standard
stands alone as a "finished work;" it says nothing about
the work that led to the finished form. There's a non-
normative companion document called the Rationale that goes
into such matters, but it doesn't address maadhuu's question.
I mention this lack of certainty so maadhuu and others will
understand that my answer is really just speculation. With
that out of the way:
First (as Walter Roberson pointed out), there's nothing
useful to do with a function's size, assuming you could get
hold of it. You can't malloc() memory and copy a function
into (or from!) it, because functons are not data: C is
specified in such a way that it can be implemented even if
instructions and data occupy completely different address
spaces, perhaps with completely different characteristics.
Nor can you do useful arithmetic on function pointers (where
the notion of function size would lurk in the background),
because you can't make arrays of functions: functions aren't
data. Knowing a function's size doesn't enable anything useful,
while at the same time requiring an implementation to be able
to supply a size could reduce the number of machines able to
implement C. Imagine a machine with 8-bit bytes in data space
and 36-bit instructions in instruction space: what is the
`sizeof' a five-instruction function? (Do *not* answer
"Twenty-two and one-half bytes.")
(By the way, Walter suggested that it was possible to
convert a function pointer to a `void*'. I'm sure this was
just a typo for `(void*)()', because he knows better: function
pointers and data pointers need not be interconvertible,
because the things they point to need not be in any way
similar.)
Second, the very notion of "the size" of a function is
rather slippery. What if the function has been expanded in-
in five or six places? Is "the size" the total size of all
expansions? If so, it might not be a compile-time constant
if the function is inlined in different translation units.
If "the size" is the memory footprint of one expansion, which
one is it? Note that different in-line expansions may well
generate different instruction counts. What if the optimizer
intermixes the in-line expansion's instructions with those of
the caller? What if the optimizer produces some instructions
that are not strictly attributable to either the caller or
to the expanded function? What if some optimizations occur
at run-time (think "JIT compiler"), using profiling data
gathered during the run, data that might vary from one run
to the next?
Third, we've been talking about a function's memory as
being made up of instructions, but there may well be other
"non-operating" components. For example, the first word of
a VAX subroutine is not an instruction, but a data construct
describing the subroutine linkage: which registers require
saving and restoring, that sort of thing. Other machines may
use even more complicated "dope vectors" -- and if they're
large enough a compiler may well find ways to let multiple
similar functions share the same dope vector, in which case
the dope vector's memory would be attributable to *all* the
functions that share it, and not chargeable to any one of
them ...
Those are some of my notions about "Why?", but as I said
earlier they are in no way authoritative.
A
Alexei A. Frounze
Keith Thompson said:
You're right about the latter.
And I've never tried doing arithmetics on function pointers (other than
assignment and equal/unequal comparison), so the use of the minus operator
on them is missing in my experience. Usually, there's no good reason to know
the size of function in bytes (whatever byte is in the program address
space).
I can think of only one reason why the size of func may matter... Whether it
fits into a fixed number of pages on a CPU with paging. But this is normally
what OS and driver developers may only be concerned about. The rest
shouldn't.
Alex
K
Keith Thompson
Eric Sosman said:
If it were useful to compute the size of a function, these particular
issues could be solved. We can take the address of a function, after
all. Even if the function is inlined, perhaps multiple times, the
address gives you something through which the function can be called
with arbitrary arguments.
Having said that, the other reasons why the size of a function is not
useful are perfectly valid.
R
Robert Gamble
So you think that speculating about the answer to a question related to
the one that was asked (for which you claim there is no definitive
answer) makes your answer any more satisfactory than mine?
Robert Gamble
R
Richard Tobin
maadhuu said:
As others have said, the C standard does not let you do this.
If you really need to do this kind of thing, it's probably possible to
do it by use of some operating-system-specific tools for examining
object files.
-- Richard
E
Eric Sosman
Robert said:
To someone who regards the Universe as a given, as a
set of arbitrary phenomena requiring no explanation, your
answer is, perhaps, satisfactory. Myself, I like having
the illusion that "there's method in it," I seek more
systematic connections between the phenomena, and I (with
hubris) presume to call these connections "explanations."
The explanations are never complete, are sometimes little
more than supposition, and are sometimes even untestable --
but yes, I find it more satisfactory to have them than to
do without them. More useful, too.
"Why must a string have a '\0' at the end?" Choose
between two possible answers: (1) "Because C does not keep
track of the number of data characters in a string, it
uses a distinguished `non-data' character to indicate where
the data ends," or (2) "Because the Standard says so."
Answers of type (1), it seems to me, promote
understanding. Those of type (2) favor memorization.
D
Dik T. Winter
Indeed, suppose the data is organised with CHAR_BIT=9, but compiled
functions use 8-bit bytes. In that case you would in general not
even get a value that as some reasonable meaning.
L
Lawrence Kirby
That's not unreasonable. Remember that sizeof's result is in units of the
type being pointed at. So if you take the difference between 2 pointers
to int, you will get a count of ints, not bytes. So takeing the difference
between 2 function pointers would at best give you a count in units of
functions. In practice however sizeof is only defined over arrays i.e.
collections of things that have the same size and doesn't make any sense
for functions.
Function pointers can be cast to other function pointer types but they
must be cast back to the original type before the funciton is called. A
function pointer may not meaningfully be converted to any pointer to data
type, including void *.
Lawrence
K
Keith Thompson
Lawrence Kirby said:
Um, maybe you shouldn't post before you've had your coffee?
}sizeof always yields a result in bytes. Pointer subtraction yields a
result in units of the type being pointed at. (I know you know that.)