[comp.sys.amiga] Bug in Manx 3.6a c.lib

nix@tolsun.oulu.fi (Tero Manninen) (05/02/89)

I haven't been able to read comp.sys.amiga lately so much as I would liked
and so I may have missed this:
Have anybody found such a bug in Manx 3.6a that it leaves dos.library
open when program compiled with cc have exited ?
This bug was found when I looked library_info in Xoper and saw an open_count
bigger than 200 for dos.library and it increased every time I ran a Manx-
compiled program..
An easy fix to this is to patch _exit.c and replace it to c.lib, c32.lib
and so on:
First declare  extern void *DOSBase;
then where all other libraries are closed:
	if (DOSBase)
		_CloseLibrary(DOSBase);
Hope this is correct, at least it works for me :-)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
	Tero Manninen,	nix@tolsun.oulu.fi

page%rishathra@Sun.COM (Bob Page) (05/03/89)

nix@tolsun.UUCP (Tero Manninen) wrote:
>Have anybody found such a bug in Manx 3.6a that it leaves dos.library
>open when program compiled with cc have exited ?

Depending on your viewpoint, it's not a bug.  The only reason to close
dos.library is to decrement the open count .. closing it does not free
any resources.  The only reason to decrement the open count is to allow
the library to be purged from RAM when the count drops to zero and
you need the memory.

Well, dos.library is in ROM, so will never get purged.  Thus closing
DOSBase doesn't accomplish anything except maybe peace of mind.  But
it does add some extra bytes to your executable.

Maybe you should team up with Leo and write CloseResource().

..bob

dwl10@uts.amdahl.com (Dave Lowrey) (05/03/89)

In article <102473@sun.Eng.Sun.COM> page@sun.UUCP (Bob Page) writes:
>
>Well, dos.library is in ROM, so will never get purged.  Thus closing
>DOSBase doesn't accomplish anything except maybe peace of mind.  But
>it does add some extra bytes to your executable.
>
However, that is still VERY sloppy coding!

Are we to assume that dos.library will ALWAYS remain in ROM?

There were alot of people that assumed that there would only  be
512K of Chip RAM, and we are now seeing the results of their assumptions.

Another point...what happens when the opencount for the library overflows?

-- 
-------------------------------------------------------------------

    "What is another word for 'Thesaurus'?"  Steven Wright

                          Dave Lowrey
                          Amdahl Corp.
                          Houston, Texas
                          (713)-850-8828
                         ...!{ames,sun,decwrl,uunet,....}!amdahl!dwl10

[ The opinions expressed <may> be those of the author and not necessarily
  those of his most eminent employer. ]

jmsc@inesc.UUCP (Miguel Casteleiro) (05/05/89)

In article <102473@sun.Eng.Sun.COM>, page%rishathra@Sun.COM (Bob Page) writes:
> nix@tolsun.UUCP (Tero Manninen) wrote:
> >Have anybody found such a bug in Manx 3.6a that it leaves dos.library
> >open when program compiled with cc have exited ?
> 
> Depending on your viewpoint, it's not a bug.  The only reason to close
> dos.library is to decrement the open count ..  [...]  Thus closing
> DOSBase doesn't accomplish anything except maybe peace of mind. [...]

   Not quite, it's a question of style and good programing education.
   You should close what you open, and free what you alloc (and don't relie
on the operating system (or the C compiler) to do that for you).
-- 
                                                                      __
 Miguel Casteleiro at                                            __  ///
 INESC, Lisboa, Portugal.                                        \\\/// Only
 UUCP: ...!mcvax!inesc!jmsc   "Life is hard and then you die."    \XX/ Amiga

griff@intelob.intel.com (Richard Griffith) (05/08/89)

While we're talking about Manx - I got a bit of a problem (this is my
own fault, I know! but...:-^... )  I wrote a little dice-rolling routine
using rand()... it works and everything is fine, except - I was trying
to work in a file-requester (Thank you Pete DaSilva :-)- but it needed
to use the 32-bit ints (to integrate easily, you see, I'm basically lazy! 
:-)  - anyway - I used srand() and rand() to seed and generate the 
random number generator - only now it won't run (sdb gives step errors),
I can't seem to find the docs for srand, rand, nor the step errors for
sdb... I know I found it once (after quite a bit of searching), but can't
seem to find it now - I have all the docs, save the RKM's (I know, but
I've been living with R. Pecks' book and the Mortimores) - Anybody
have any Ideas?

                     *shrug* (GOD! I've gotta comment my code better :-)

                               - griff
--
* Richard E. Griffith                     * Cyrus Hammerhand             *
*    "griff"		                  * Household of the Golden Wolf *
* BiiN, Hillsboro Ore.	                  * Dragons' Mist                *
* UUCP: ...[!uunet]!tektronix!biin!griff  * An Tir                       *
**************************************************************************
* These are MY opinions, if BiiN wanted them, They'd pay for `em!        *

rap@rap.ardent.com (Rob Peck) (05/10/89)

In article <GRIFF.89May8114846@intelob.intel.com> griff@intelob.intel.com (Richard Griffith) writes:
>
>:-)  - anyway - I used srand() and rand() to seed and generate the 
>random number generator - only now it won't run (sdb gives step errors),
>I can't seem to find the docs for srand, rand, nor the step errors for

    !!!!!!
You REALLY need the RKM's... 
    !!!!!!

/* ********************************************************************* */
	extern long RangeSeed;

	unsigned long rand_32bits, maxval_32bits;
	unsigned long constrained_rand_32bits, initial_value32bits;

	RangeSeed = initial_value32bits;

	rand_32bits = FastRand();
	constrained_rand_32bits = RangeRand(maxval_32bits);
/* ********************************************************************* */

	where:
		0 <= constrained_randno_32bits <= maxvalue_32bits


The random numbers are established via the "usual manner", if I remember
right, exclusive or-ing with something or other and then shifting by some
amount or something like it.  Also as I remember, RangeRand calls FastRand,
and thus both use the established RangeSeed.

These functions are in amiga.lib.  Note that if you are still compiling
with Lattice 3.03 (which, strangely enough, sometimes happens to me if
I just don't wanna reach for the main Lattice book (which has 5.02 in it),
you won't see these... they came in at the release of the 1.2 amiga.lib
and Lattice 3.03 hasn't got em.

If it is COST that's got you waiting to get an RKM, I'll sell you my
1.2 versions of the RKM's (a COMPLETE set, Intuition, Exec, and Libraries;
maybe even Hardware ... unsure) for 1/3 of the cover price.  The 1.3 will
be better organized and have better examples, but the 1.2 will at least
provide a stopgap until you can scare up a few more funds.  Personally
I am a book-a-holic, and actually collected two sets of the manuals.
Now, for Richard, I can make the extra set available.  (and it'd help
me to get the 1.3 versions, WHEN they come out).


Rob Peck

griff@intelob.intel.com (Richard Griffith) (05/11/89)

Thanks for the offer, Rob, but when I bought my `2000 the RKM's were
in short supply, as I have already noted - I've been relying on Sybex
(again, thank you...:-) for info....I now have 1.3 and will likely 
be trying to get the funds for the RKM's RSN. (let's see, review is
this week so....:-)  By the way - I'm still a Manx user (3.6 - God! I
love sdb!)  The only way I'd change that at this point would be if 
someone came out with a Modula-II that used a similar debugging environment.
(With an integrated editor, I'd start looking around for what I don't
need at home to sell off...:-) :-) 

                 Again - I think I'll wait `till my raise (I hope) kicks
                 in to get the 1.3's...

                              - griff
--
* Richard E. Griffith                     * Cyrus Hammerhand             *
*    "griff"		                  * Household of the Golden Wolf *
* BiiN, Hillsboro Ore.	                  * Dragons' Mist                *
* UUCP: ...[!uunet]!tektronix!biin!griff  * An Tir                       *
**************************************************************************
* These are MY opinions, if BiiN wanted them, They'd pay for `em!        *

"kosma@ALAN.LAAC-AI.Dialnet.Symbolics.COM"@alan.kahuna.decnet.lockheed.com (05/24/89)

Received: from BLAISE.LAAC-AI.Dialnet.Symbolics.COM by ALAN.LAAC-AI.Dialnet.Symbolics.COM via CHAOS with CHAOS-MAIL id 22811; Thu 18-May-89 15:53:09 PDT
Date: Thu, 18 May 89 15:53 PDT
From: Montgomery Kosma <kosma@ALAN.LAAC-AI.Dialnet.Symbolics.COM>
Subject: Re: Bug in Manx 3.6a c.lib
To: "eagle::amiga-relay%udel.edu"@KAHUNA.LAAC-AI.Dialnet.Symbolics.COM
Message-ID: <19890518225308.1.KOSMA@BLAISE.LAAC-AI.Dialnet.Symbolics.COM>
 
>    amount or something like it.  Also as I remember, RangeRand calls FastRand,
>    and thus both use the established RangeSeed.
> 
>    These functions are in amiga.lib.  Note that if you are still compiling
>    with Lattice 3.03 (which, strangely enough, sometimes happens to me if
>    I just don't wanna reach for the main Lattice book (which has 5.02 in it),
>    you won't see these... they came in at the release of the 1.2 amiga.lib
>    and Lattice 3.03 hasn't got em.
 
>    Rob Peck
 
Hi...
 
I'm new to the net and relatively new to C on the amiga, (having spent
most of my time hacking Symbolics lisp), and have a quick related
question.  I'm using Manx 3.6, and have an incomplete set of the RKMs,
and was recently wondering about the RangeRand function.  The RKMs
mention amiga.lib, as it is mentioned above in connection with Lattice.
Does this library exist as a part of the Manx libraries included with
3.6, as a part of the 1.3 libraries, or what?  I haven't found anything
too clear on this in the manuals that I have, so if a good source
describing libraries, etc., exists, a recommendation would be in order.
 
BTW, please let me know if I've screwed up at all in subject matter or
form of submission . . . only so much you can learn by observing w/o
getting involved yourself.
 
 
 
Montgomery N. Kosma
LE03472%portal.decnet.lockheed.com@austin.lockheed.com