850031m@aucs.uucp (Ross MacGregor) (01/19/90)
Im trying to compile some code that contains a reference to realloc().
Im using Manx3.6a. This function, according to the manual, should be
in c.lib, but when I link the object code I get "Undefined symbol: realloc".
What's going on? Is it really a macro I didn't #include ?
Or is it a real bug/omission on Manx's part?
--
---------
Ross MacGregor | "
E-mail: 850031m@AcadiaU.CA | COMPUTER this!
UUCP: {uunet|watmath|utai}!cs.dal.ca!aucs!850031m | " tdesjardins@lion.waterloo.edu (Tim Desjardins) (01/19/90)
In article <1990Jan19.005944.5971@aucs.uucp> 850031m@aucs.UUCP (Ross MacGregor) writes: >Im trying to compile some code that contains a reference to realloc(). >Im using Manx3.6a. This function, according to the manual, should be >in c.lib, but when I link the object code I get "Undefined symbol: realloc". > >What's going on? Is it really a macro I didn't #include ? >Or is it a real bug/omission on Manx's part? I don't think it's anything you're doing the c32.lib is also missing realloc(). I use malloc and free the stuff that was supposed to be realloced. I had to do this to get lex to compile. Maybe 5.0 will have realloc() in the stdlib, one can only hope. If someone has the developers version handy, they can dig into the lib source ( I think ) and see if it's there. Hope this helps. Tim Desjardins. tdesjardins@lion.waterloo.{edu|cdn}
atheybey@lcs.mit.edu (Andrew Heybey) (01/19/90)
Realloc is indeed missing, at least from the earlier versions of Manx.
Here is a fairly old posting that contains the source to realloc().
As mentioned in the post, it is also available from Manx's bulletin
board.
UID: 8374
Path: bloom-beacon!husc6!linus!raybed2!rayssd!galaxia!amanpt1!mrr
From: mrr@amanpt1.UUCP (Mark Rinfret)
Newsgroups: comp.sys.amiga
Subject: Aztec realloc() for 3.4b
Date: 22 Jan 88 18:56:18 GMT
Organization: Aquidneck Management Associates
Lines: 84
[Note: I made an error in the example portion of a previous posting.
Hopefully, I cancelled that message and you'll only see this one.
If you did get the first posting, please discard it and save this
one. Realloc() must be positioned BEFORE movmem in order for
dependencies to be resolved correctly. ]
I just "rediscovered" that realloc() was missing from my Aztec libraries
(3.4b) when I tried to compile and link the "subst" (substitute strings)
program posted recently to comp.misc.sources. I guess, somewhere back in
my mental archives, there's a wisp of a memory of a discussion about that
problem, but, since it didn't affect me at the time, I didn't take the time
to make note of it. All that aside, I just got the missing function from the
Manx bulletin board and thought I'd post it for those who might need it.
I recommend putting it in your "lib" directory. Compile it for each
memory model that you use and add it to your existing libraries. The
following example installs realloc() before movmem() in c.lib and c32.lib:
cc realloc.c
lb c.lib -a movmem realloc.o
cc +L realloc.c
lb c32.lib -a movmem realloc.o
If you're working on floppy disks, be sure that there's enough room for
two copies of the library being modified (during the modification). LB
will delete the original and replace it with the new version if it is
successful.
/***********************************************************************
The following is the source code for realloc. Compile it with the
appropriate memory model options, and insert in the c libraries.
***********************************************************************/
/* Copyright (C) 1987 by Manx Software Systems, Inc. */
unsigned long _Heapsize = 40 * 1024L;
typedef long size_t;
#define bump(p,i) ((l_t *)((char *)(p)+(i)))
#define ptrdiff(p1,p2) (unsigned long)((char *)(p1)-(char *)(p2))
typedef struct list {
struct list *next;
} l_t;
static l_t first, *current;
static l_t *endmarker = &first, *restart = &first;
static size_t keep;
#define INUSE 1
#define inuse(p) (*(size_t *)(p)&INUSE)
#define markblk(p) (*(size_t *)(p) |= INUSE)
#define unmark(p) (*(size_t *)(p) &= ~INUSE)
#define chain(p) ((l_t *)(*(size_t *)(p) & ~INUSE))
#define BLOCK (512*sizeof(l_t)) /* # of bytes to ask sbrk for */
char *
realloc(area, size)
register char *area; unsigned size;
{
register char *cp, *end;
size_t osize;
char *movmem();
end = (char *)chain((l_t *)area-1);
if ((osize = ptrdiff(end, area)) > size) {
osize = size;
end = (char *)bump(area, osize);
}
free(area);
if ((cp = movmem(size)) != 0 && cp != area) {
movmem(area, cp, osize);
if ((char *)current >= area && (char *)current < end)
*(size_t *)bump(cp, ptrdiff(current,area)) = keep;
}
return cp;
}
/*EOF*/
--
< Mark R. Rinfret, mrr@amanpt1.ZONE1.COM | ...rayssd!galaxia!amanpt1!mrr >
< Aquidneck Management Associates Home: 401-846-7639 >
< 6 John Clarke Road Work: 401-849-8900 x56 >
< Middletown, RI 02840 "If I just had a little more time...">
--
Andrew Heybey, atheybey@ptt.lcs.mit.edu, uunet!ptt.lcs.mit.edu!atheybeycrash@boake2 (Frank J. Edwards) (01/20/90)
Ross, Don't feel bad -- it took me awhile to find it also! I had actually decoded how the malloc() call worked, and written my own realloc()! The file you need is called "heapmem.o" (or it's other various flavors, depending on what memory model you're using). It can be included in the link list by just specifying its name, i.e. ln -o indian chief.o big.o mem.o heapmem.o -lc The Manx linker will automagically search the CLIB environment variable for a list of directories to look in to find `heapmem.o' and `c.lib'. So that's what's missing from the link line. However, there's a bug in the Version 3.6a `heapmem.o' for which I have included my patches. Before explaining the patches, this is the file I'm working with. First of all, this bug DOES NOT apply to the 32-bit integer mode. (Another good reason to always use 32-bit ints :-). Here is the file I patched: Lib/heapmem.o ----rwed 992 2 <date> <time> In the following descriptions, realloc+<nn> is the location of the instruction <nn> bytes after the realloc symbol AFTER linking. However, there should only be one instance of each of the `from' patterns given below, so a simple search for a binary value should find only one match. Use <insert_favorite_file_editor_here> to locate and patch each bug. At or near location realloc+84, patch the following: from $2F2DFFFC ; move.l -4(a5),-(a7) to $3F2DFFFE ; move.w -2(a5),-(a7) This fixes a call to movmem() which expects (char *, char *, int) and was being called as (char *, char *, long)!!! Similarly, the stack will need to be cleaned up by 10 bytes now, instead of 12. At or near location realloc+100: from $4FEF000C ; lea 12(a7),a7 to $4FEF000A ; lea 10(a7),a7 Well, I hope this hasn't confused too many Manx users out there. Maybe it will explain to a few people why their code doesn't work!! Of course, I've never told Manx about any of this... would someone care to do that? Personally I think Amiga programmers _NEED_ a challenge like this to keep'em on their toes :-) :-) :-) ----- Kirk: "Spock, where's that power you promised?!" Spock: "One *damn* minute, Admiral!" ----- Please use "uunet!pdn!boake2!ckctpa!crash" as "ckctpa" does not (yet :-) appear in the USEnet maps. (Sheeesh! I just sent it yesterday!) ----- Frank J. Edwards ComputerKnowledge Corp 2677 Arjay Court 12740 Hillcrest, Suite 212 Palm Harbor, FL 34684-4505 Dallas, TX 75230 Phone: (813) 786-3675 (214) 385-9700 / (800) 227-9700
murphy@pur-phy (William J. Murphy) (02/23/90)
Recently, someone posted about realloc() missing in Manx 3.4b C compiler. I don't mean to come off stupid, but they didn't mean that it was missing from Manx 5.0 did they? I am confused since it came at the time of the release of 5.0. I saved the original posting, but I can't seem to figure out if they meant 5.0 or not. A simple yes or no is all I ask. Thanks, -- Bill Murphy murphy@newton.physics.purdue.edu Enjoying my Amiga 2000, but holding out for a real computer: The Amiga 3000!!
golson@grapevine.EBay.Sun.COM (Greg Olson) (02/24/90)
In article <3161@pur-phy> murphy@pur-phy (William J. Murphy) writes: >Recently, someone posted about realloc() missing in Manx 3.4b C compiler. >I don't mean to come off stupid, but they didn't mean that it was missing >from Manx 5.0 did they? I am confused since it came at the time of the >release of 5.0. > >I saved the original posting, but I can't seem to figure out if they meant >5.0 or not. A simple yes or no is all I ask. > You might mean me, Bill. To answer your question, yes, realloc is included in 5.0, but mktemp is not (but is documented, similar to realloc in 3.4). --Greg