 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Ed Mulroy [TeamB]
Guest
|
 Posted: Mon Jul 07, 2003 2:42 pm Post subject: Re: Access to _default87 ? |
 |
|
You might want to look at the comments and code in the file ctrl87.asm
I have no idea why calling a function is not acceptable. Just create a
static function in your lib which calls it with the appropriate calling arg
and use #pragma startup to force that function to be called before main or
WinMain.
.. Ed
| Quote: | Helmut Giese wrote in message
news:3f097fc1.9230472 (AT) forums (DOT) borland.com...
for users of a library I provide, I need to set other options for the
floating point processor than the defaults the compiler provides. I
know about the function '_controlfp', but this function has to be
called.
Normally no problem, but you know how users are - they may call it or
they may not. I figured that by setting (overwriting)
extern unsigned int _RTLENTRY _default87;
(found in float.h) from within my library's *header file*, every
program which uses my library would automagically start with the
correct options.
Only thing is: I am unable to influence this variable. Whatever syntax
I use I end up creating a variable of my own - which the startup code
happily ignores, of course.
Any ideas will be greatly appreciated.
|
|
|
| Back to top |
|
 |
Helmut Giese
Guest
|
| Posted: Mon Jul 07, 2003 5:30 pm Post subject: Re: Access to _default87 ? |
|
|
On Mon, 7 Jul 2003 10:42:27 -0400, "Ed Mulroy [TeamB]"
<ed (AT) mulroyREMOVETHESECHARS (DOT) org> wrote:
Hello Ed,
| Quote: | You might want to look at the comments and code in the file ctrl87.asm
I did (and deflt87.c and probably everything else which is 80x87 |
related - 'grep -nid' to the rescue) but I cannot get access to this
variable. Apparently the RTL does not export this symbol.
I remembered the ol' stklth variable from DOS times where you could
override the default and provide a different size for the stack, and
just had the idea / hope that the same thing would be possible with
_default87.
| Quote: | I have no idea why calling a function is not acceptable. Just create a
static function in your lib which calls it with the appropriate calling arg
and use #pragma startup to force that function to be called before main or
WinMain.
In this case (initialisation paths are different depending on context) |
I *think* it would have been the easiest solution to just add it to
the header file.
Thanks for your comments.
Helmut Giese
|
|
| Back to top |
|
|
Ed Mulroy [TeamB]
Guest
|
| Posted: Mon Jul 07, 2003 7:43 pm Post subject: Re: Access to _default87 ? |
|
|
You might try static linking so the variable isn't buried into a DLL
somewhere.
.. Ed
| Quote: | Helmut Giese wrote in message
news:3f09abf8.716532 (AT) forums (DOT) borland.com...
|
|
|
| Back to top |
|
|
Helmut Giese
Guest
|
| Posted: Mon Jul 07, 2003 9:13 pm Post subject: Re: Access to _default87 ? |
|
|
Hi Ed,
JFYI, one reason the "header file solution" looked attractive was that
one of my attempts to use _controlfp failed:
- I had put it into a function which was called at lib / DLL
initialisation time (and was building my lib as a DLL).
- I saw it execute but
- when the program ran I still had the normal / default setting.
Doing it at this point in time was apparently to early: The startup
code of the app had not yet run. So it ran a moment later and undid
what I had done via _controlfp from within my DLL.
As I said, FYI. I found a function which has to be called by any
application using this DLL / lib and put the code there. So for the
moment the issue is closed - we'll see how it works in every day use.
Thanks for your attention
Helmut Giese
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
