<?xml version="1.0" encoding="UTF-8" ?>
<?xml-stylesheet type="text/xsl" href="https://community.arm.com/utility/feedstylesheets/rss.xsl" media="screen"?><rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:slash="http://purl.org/rss/1.0/modules/slash/" xmlns:wfw="http://wellformedweb.org/CommentAPI/"><channel><title>Pointer to function problems</title><link>https://community.arm.com/developer/tools-software/tools/f/keil-forum/21786/pointer-to-function-problems</link><description> 
Hi, 

 
This post is about the classic problem creating pointers to
function using the overlay procedure. 

 
The reference in the manual suggest the OVERLAY directive to
modify the call tree that is automatically generated by the linker.
But what happeneds</description><dc:language>en-US</dc:language><generator>Telligent Community 10</generator><item><title>RE: Pointer to function problems</title><link>https://community.arm.com/thread/151208?ContentTypeID=1</link><pubDate>Mon, 28 Jan 2008 14:13:17 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:70d15250-17b9-4b65-b73d-5cb0b33277e8</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;and in some situations the user must be knowledgeable enough to
help the compiler/linker. If it was a general solution and not a
hack, you would never need to specify if a function is reentrant or
not.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
oh WOW, I did not know that. I always thought you were supposed to
know the tools you worked with.&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Pointer to function problems</title><link>https://community.arm.com/thread/150659?ContentTypeID=1</link><pubDate>Mon, 28 Jan 2008 11:56:01 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:7053d7d7-3281-47d4-a567-42fa2fdcd2f6</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;Most C compilers generate code that spends a lot of run time
pushing and popping onto a stack, and uses indirect references to
access commonly used variables.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
No, they don&amp;#39;t.&lt;/p&gt;

&lt;p&gt;
Most processors have a suitable set of instructions for
implementing a stack, and suitable base pointer registers for
accessing parameters and auto variables relative the current stack
frame.&lt;/p&gt;

&lt;p&gt;
At function entry, a typical processor has to capture the current
stack pointer as a base address for accessing parameters and auto
variables. It then as to adjust the stack pointer to allocate room
for auto variables. This can often be done with two instructions -
neither instruction requiring any memory reference.&lt;/p&gt;

&lt;p&gt;
At function exit, a typical processor has to restore the current
stack pointer, which can normally be done with a single register
assign.&lt;/p&gt;

&lt;p&gt;
Standard pipelining can normally perform multiple instructions
concurrently (especially instructions that doesn&amp;#39;t require explicit
memory accesses).&lt;/p&gt;

&lt;p&gt;
The net result is that for most programs, a very small part of the
processor capacity is used for the stack manipulation.&lt;/p&gt;

&lt;p&gt;
The exception is when a large number of calls are to miniature
functions with very few instructions in them. But in such cases, more
processor capacity is normally lost in cache misses than in the stack
manipulation. But then the normal - and trivially simple - way to
handle such cases (if it is important) is to inline tiny functions.
Either automatically, or by use of an inline keyword. The removal of
the call statement will in many cases allow inlining without
increasing the code size. And good code optimizers will perform the
optimization after the inlining, allowing prefetches and optimum use
of registers etc.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;I wouldn&amp;#39;t call it a hack, so much as a fairly powerful
optimization.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
The reason I called the Keil linker work a hack is because it is a
very heavy-duty work-around to make the C51 processor do tricks it
was specifically not inteded to do. It is a hack because it isn&amp;#39;t a
general solution to the problem. It can only perform it&amp;#39;s workaround
magic for a specific limited set of problems, and in some situations
the user must be knowledgeable enough to help the compiler/linker. If
it was a general solution and not a hack, you would never need to
specify if a function is reentrant or not.&lt;/p&gt;

&lt;p&gt;
For other processor architectures, it is normally enough to
specify if you want the compiler to optimize for speed, size or
&amp;quot;debugability&amp;quot;.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Pointer to function problems</title><link>https://community.arm.com/thread/150268?ContentTypeID=1</link><pubDate>Mon, 28 Jan 2008 11:28:56 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:d629712e-9699-48c4-a3b3-9731c63f1c38</guid><dc:creator>Drew Davis</dc:creator><description>&lt;p&gt;&lt;p&gt;
I wouldn&amp;#39;t call it a hack, so much as a fairly powerful
optimization. Most C compilers generate code that spends a lot of run
time pushing and popping onto a stack, and uses indirect references
to access commonly used variables. The call tree analysis allows you
to eliminate all that code and directly reference locals, temps, and
parameters. Sometimes it would be nice to have this option on other
architectures, even those that are much better suited to maintaining
a stack and indirect references. For a great many programs, you don&amp;#39;t
actually need the features that all that run-time stack manipulation
provides.&lt;/p&gt;

&lt;p&gt;
The cost of eliminating the stack, however, is fairly severe -- no
recursion, no reentrancy, and limitations on the use of function
pointers.&lt;/p&gt;

&lt;p&gt;
If you want, though, you can just declare all your functions
&lt;b&gt;reentrant&lt;/b&gt; and get the behavior you&amp;#39;d expect of a &amp;quot;normal&amp;quot; C
compiler without the &amp;quot;hack&amp;quot;. I don&amp;#39;t think you&amp;#39;ll like the results on
the 8051 so much.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Pointer to function problems</title><link>https://community.arm.com/thread/149827?ContentTypeID=1</link><pubDate>Sat, 26 Jan 2008 23:50:48 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:e11c2905-ac5b-4cab-ab95-20c3adb7da4f</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;What the Keil linker does is a hack. &lt;b&gt;But it is the only
known method&lt;/b&gt; to make the &amp;#39;51 processor at least reasonably
compatible with any high or medium level language.&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Exactly!&lt;/p&gt;

&lt;p&gt;
It brings its problems - like all this call-tree analysis stuff -
but can the OP suggest a better way?&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Pointer to function problems</title><link>https://community.arm.com/thread/149339?ContentTypeID=1</link><pubDate>Sat, 26 Jan 2008 17:51:38 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b3b068a5-c385-4f41-a702-102cb4b96b88</guid><dc:creator>ImPer Westermark</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;effectively, this does at link time what a real stack does at
runtime.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Which means that recursive function call chains - or unknown call
chains (pointers) - are not suited for a &amp;#39;51 processor.&lt;/p&gt;

&lt;p&gt;
I don&amp;#39;t know about any other architecture where the linker knows
about the internals of all functions. A linker normally have to fixup
addresses depending on order and size of individual modules.&lt;/p&gt;

&lt;p&gt;
What the Keil linker does is a hack. But it is the only known
method to make the &amp;#39;51 processor at least reasonably compatible with
any high och medium level language. Keil is basically continuing
something that was started with the PLM51 language from Intel.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Pointer to function problems</title><link>https://community.arm.com/thread/148879?ContentTypeID=1</link><pubDate>Sat, 26 Jan 2008 13:06:23 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:8e8ef188-cb3a-4f7f-8a33-b950050cfb45</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;&amp;quot;Is it that hard for the linker?&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
If you need to ask that question, then you haven&amp;#39;t understood the
problem!&lt;/p&gt;

&lt;p&gt;
It is not just &amp;quot;hard&amp;quot; - it is impossible!&lt;/p&gt;

&lt;p&gt;
The reason the Linker needs to know the call tree is so that it
can know what data can be &lt;b&gt;overlaid&lt;/b&gt;.&lt;/p&gt;

&lt;p&gt;
The Linker needs to do this at the time the project is built -
therefore it cannot possibly know what functions might end-up getting
called via a pointer assigned at run time!&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&amp;quot;with KEIL i see it like a flaw...&amp;quot;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
The problem is that the 8051 architecture is inherently unsuited
to putting parameters &amp;amp; automatic variables on the stack - which
is what &amp;quot;normal&amp;quot; compilers do.&lt;br /&gt;
Keil&amp;#39;s &amp;quot;workaround&amp;quot; for this is to put parameters &amp;amp; automatic
variables into fixed memory locations. Of course, this has some
drawbacks - which is why &amp;quot;normal&amp;quot; compilers don&amp;#39;t do it when they can
use the stack!&lt;/p&gt;

&lt;p&gt;
&lt;b&gt;Overlaying&lt;/b&gt; then recovers some of this fixed memory usage,
by allowing mutually-exclusive functions to share memory locations -
effectively, this does at link time what a real stack does at
runtime.&lt;/p&gt;

&lt;p&gt;
See: &lt;a href="http://www.keil.com/appnotes/docs/apnt_129.asp"&gt;http://www.keil.com/appnotes/docs/apnt_129.asp&lt;/a&gt;&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Pointer to function problems</title><link>https://community.arm.com/thread/138656?ContentTypeID=1</link><pubDate>Sat, 26 Jan 2008 12:33:46 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:616087c5-3162-4f40-9f42-1b70a128ada5</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;In my experience libraries aren&amp;#39;t used all that much in
C51&lt;/i&gt;&lt;br /&gt;
I use them a lot HOWEVER,&lt;br /&gt;
In my experience libraries &lt;b&gt;for which you do not have access to the
source&lt;/b&gt; aren&amp;#39;t used all that much in C51.&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Pointer to function problems</title><link>https://community.arm.com/thread/135263?ContentTypeID=1</link><pubDate>Sat, 26 Jan 2008 11:26:56 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:e1c9914b-ae03-4bd7-ba9d-46f138565c0f</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;When i say &amp;quot;complete&amp;quot; i mean that if you are the end user &amp;quot;you
don&amp;#39;t need to add or modify anything&amp;quot;. Not even the call
tree.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
I&amp;#39;m quite sure we all understand your wish. It&amp;#39;s just that we know
better than to expect such wishes to come true.&lt;/p&gt;

&lt;p&gt;
As I said before, not all those nice design patterns lend
themselves well to the way a 8051 works. Arbitrary use of function
pointers is &lt;b&gt;not&lt;/b&gt; a good idea on an 8051.&lt;/p&gt;

&lt;p&gt;
In my experience libraries aren&amp;#39;t used all that much in C51.
You&amp;#39;ve just come across one of the reasons. Another is that 8051
programs are usually small enough that pre-compiled libraries don&amp;#39;t
offer significant advantage over re-compilation.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Pointer to function problems</title><link>https://community.arm.com/thread/135260?ContentTypeID=1</link><pubDate>Sat, 26 Jan 2008 09:57:53 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:04f7c403-ff13-4d10-b850-c7e79a8bdef8</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;But what is so difficult about pointer to functions and x51. Is
it that hard for the linker? In contrast with KEIL i see it like a
flaw...&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
It has NOTHING to do with Keil (well in a way it does - if they
had chosen a horrible implementation, there would be no call
tree)&lt;/p&gt;

&lt;p&gt;
It has EVERYTHING to do with the &amp;#39;51 architecture. The &amp;#39;51 is
extremely limited re stack space (and fetches via the stack pointer
are very processor heavy), and if the call tree had not been
implemented you would have a bunch of stack overflows and a very
sluggish performance.&lt;/p&gt;

&lt;p&gt;
Thus, because of the ARCHITECTURE of the &amp;#39;51 you &amp;quot;In contrast with
KEIL i see it like a flaw&amp;quot; that Keil did the most effieient
inplementation possible.&lt;/p&gt;

&lt;p&gt;
So, as often said before &lt;b&gt;if you do not want to be concerned
with processor architecture, stay away from the &amp;#39;51&lt;/b&gt;&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Pointer to function problems</title><link>https://community.arm.com/thread/124407?ContentTypeID=1</link><pubDate>Sat, 26 Jan 2008 09:17:44 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b2eef328-3553-4ad9-a92e-77bc39081649</guid><dc:creator>Chris Houtouridis</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;... but i believe that a library must be complete for the end
user. How can the user modify the call tree if he doesn&amp;#39;t know how
the library works. He is just the user.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
When i say &amp;quot;complete&amp;quot; i mean that if you are the end user &lt;b&gt;&amp;quot;you
don&amp;#39;t need to add or modify anything&amp;quot;. Not even the call tree&lt;/b&gt;.
It&amp;#39;s a bad idea to ask for the user to know how your library works.
And even if you know how to trick the call tree, probably one year
later you will not.&lt;br /&gt;
That&amp;#39;s why i choose to use the name of the calleable function and not
a pointer to it.&lt;/p&gt;

&lt;p&gt;
But what is so difficult about pointer to functions and x51. Is it
that hard for the linker? In contrast with KEIL i see it like a
flaw...&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Pointer to function problems</title><link>https://community.arm.com/thread/113604?ContentTypeID=1</link><pubDate>Sat, 26 Jan 2008 07:13:47 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:579a3cfc-ed26-43ac-972d-1d80eedef260</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;The only thing in question is: how should the library gain
access to this user-provided function?&lt;br /&gt;
The 2 choices are:&lt;br /&gt;
1. By name;&lt;br /&gt;
2. By a pointer.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;Since the pointer is a Really Bad Idea for an 8051, that really
only leaves 1 option...&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
If the library is written for &amp;#39;51 purposes (no function pointers
&lt;i&gt;but calleable by name&lt;/i&gt;) the call tree is not the end users job
but the linkers.&lt;/p&gt;

&lt;p&gt;
Andy, we DO agree. even if &amp;quot;you say tomahtos and I say
tomatoes&amp;quot;&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Pointer to function problems</title><link>https://community.arm.com/thread/100196?ContentTypeID=1</link><pubDate>Sat, 26 Jan 2008 06:57:43 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b30ff59f-2f16-4bdb-a394-c94e9061dd86</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
But the library &lt;i&gt;&lt;b&gt;is&lt;/b&gt;&lt;/i&gt; complete!&lt;/p&gt;

&lt;p&gt;
This &amp;quot;callback&amp;quot; function (or whatever it is) must always be
supplied by the end user.&lt;/p&gt;

&lt;p&gt;
The only thing in question is: how should the library gain access
to this &lt;i&gt;&lt;b&gt;user-provided&lt;/b&gt;&lt;/i&gt; function?&lt;br /&gt;
The 2 choices are:&lt;br /&gt;
&lt;b&gt;1.&lt;/b&gt; By name;&lt;br /&gt;
&lt;b&gt;2.&lt;/b&gt; By a pointer.&lt;/p&gt;

&lt;p&gt;
Since the pointer is a Really Bad Idea for an 8051, that really
only leaves 1 option...&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Pointer to function problems</title><link>https://community.arm.com/thread/100190?ContentTypeID=1</link><pubDate>Sat, 26 Jan 2008 06:14:46 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:5cde5b14-9d7d-4ba1-be9a-04146855c15f</guid><dc:creator>erik  malund</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;This is true, but i believe that a library must be complete for
the end user. How can the user modify the call tree if he doesn&amp;#39;t
know how the library works. He is just the user.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
If the library is written for &amp;#39;51 purposes (no function pointers)
the call tree is &lt;i&gt;not the end users job&lt;/i&gt; but the linkers.&lt;/p&gt;

&lt;p&gt;
Erik&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Pointer to function problems</title><link>https://community.arm.com/thread/75934?ContentTypeID=1</link><pubDate>Sat, 26 Jan 2008 05:34:40 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:b6c9387b-094b-416b-af7a-6beaed385938</guid><dc:creator>Chris Houtouridis</dc:creator><description>&lt;p&gt;&lt;p&gt;
Thanks to all for the prompt answer.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&lt;br /&gt;
Then you&amp;#39;ve just stuck yourself between a rock and a very hard place
--- and for no particularly good reason, either. Think really hard if
you have to go there.&lt;br /&gt;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
I have to say that the way Andy Neil suggests is the way I&amp;#39;m
already doing it. But for someone who try to translate code from a
compiler to another(like me) is a very difficult procedure. I&amp;#39;m
working in education and i find the keil debugger user/student
friendly, but still the translation of a library and the whole
documentation is a nightmare.&lt;/p&gt;

&lt;p&gt;
&lt;i&gt;&lt;br /&gt;
The end user that supplies the callback is the one that builds the
complete program, and thus the one that needs to fix up the call
tree.&lt;br /&gt;&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
This is true, but i believe that a library must be complete for
the end user. How can the user modify the call tree if he doesn&amp;#39;t
know how the library works. He is just the user.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Pointer to function problems</title><link>https://community.arm.com/thread/49323?ContentTypeID=1</link><pubDate>Fri, 25 Jan 2008 11:22:45 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:a8f0bd8a-60ec-4ead-92ab-fdcc5a6d2c05</guid><dc:creator>HansBernhard Broeker</dc:creator><description>&lt;p&gt;&lt;p&gt;
&lt;i&gt;But what happeneds if we don&amp;#39;t know the name of the indirect
function the pointer calls? Yes this is true.&lt;/i&gt;&lt;/p&gt;

&lt;p&gt;
Then you&amp;#39;ve just stuck yourself between a rock and a very hard
place --- and for no particularly good reason, either. Think
&lt;b&gt;really&lt;/b&gt; hard if you have to go there.&lt;/p&gt;

&lt;p&gt;
Not all techniques that work well for keeping big software systems
under control are equally applicable for small microcontrollers,
particularly the 8051. Passing around pointers to callback functions
is definitely one of those. It seriously gets in the way.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Pointer to function problems</title><link>https://community.arm.com/thread/88835?ContentTypeID=1</link><pubDate>Fri, 25 Jan 2008 09:54:50 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:dd363269-cd91-4114-86f4-c407461235c2</guid><dc:creator>Drew Davis</dc:creator><description>&lt;p&gt;&lt;p&gt;
The end user that supplies the callback is the one that builds the
complete program, and thus the one that needs to fix up the call
tree.&lt;/p&gt;

&lt;p&gt;
See the &lt;b&gt;reentrant&lt;/b&gt; keyword for declaration functions that
push params and locals onto a traditional stack. You&amp;#39;ll find that the
code is likely bigger and slower, as it has to manipulate pointers in
software. The 8051 architecture just doesn&amp;#39;t have good support for
pointers.&lt;/p&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item><item><title>RE: Pointer to function problems</title><link>https://community.arm.com/thread/49328?ContentTypeID=1</link><pubDate>Fri, 25 Jan 2008 09:41:31 GMT</pubDate><guid isPermaLink="false">dd9e70c8-6d3c-4c71-b136-2456382a7b5c:da143f4e-4114-4514-b901-1585b6ee7fff</guid><dc:creator>Andy Neil</dc:creator><description>&lt;p&gt;&lt;p&gt;
Do you really have to use a pointer?&lt;/p&gt;

&lt;p&gt;
Can&amp;#39;t you just insist that the library user must provide their
function(s) with a specific name - rather like the &amp;#39;C&amp;#39; language
insists that the program entry point must be called main() ?&lt;/p&gt;

&lt;pre&gt;
//lib_file.h
// ...
void fun( void );          // The user must provide this function

void module_init( void );  // Pointer no longer needed
void module( void );
&lt;/pre&gt;

&lt;p&gt;
&lt;/p&gt;

&lt;pre&gt;
//lib_file.c&lt;br /&gt;
//--------------------------------&lt;br /&gt;
void module_init( void )&lt;br /&gt;
{
        // Pointer initialisation no longer required&lt;br /&gt;
}

//----------------------&lt;br /&gt;
void module (void)&lt;br /&gt;
{
        //code
        // ...
        fun();    // Just call the function by name
        // code&lt;br /&gt;
}
&lt;/pre&gt;
&lt;/p&gt;&lt;div style="clear:both;"&gt;&lt;/div&gt;</description></item></channel></rss>