shf@well.UUCP (Stuart H. Ferguson) (08/04/88)
I'm trying to convert a program that compiles under Lattice C into a Manx C program, and I've run into weird snags. (This is "Conquest" from an early Fish disk, BTW.) It was originally a Unix program and appeared to require little modification to make it work on the Amiga (except that it fails to "free" some "malloc"ed structures -- tsk, tsk), but it will not run correctly when compiled using Aztec C with +L option. I've looked at it with SDB and CANNOT for the life of me figure out what is causing the crash. The program allocates some memory and assigns this is to a structure, saying: pplanet = (tplanet *) malloc (sizeof(tplanet)); but when it tries to store to the structure, it (sometimes!) crashes with Guru 3. The statement in question is: pplanet->number = <expression>; The pointer is word aligned (as it should be), and "number" is the first field in the structure so it doesn't appear to be an alignment problem. Any suggestions? Oh, it also compiles and works fine on our VMS Vax; just had to change the Read() of a RAW console window to a SYS$QIO... Any discussion of the code-level differences of Manx and Lattice could also be useful. Thanx in advance. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (shf@Solar.Stanford.EDU)
berry@stsci.EDU (Jim Berry) (08/04/88)
From article <6711@well.UUCP:, by shf@well.UUCP (Stuart H. Ferguson):
:
: I'm trying to convert a program that compiles under Lattice C into a Manx C
: program, and I've run into weird snags. (This is "Conquest" from an early
: pplanet = (tplanet *) malloc (sizeof(tplanet));
:
: but when it tries to store to the structure, it (sometimes!) crashes with
: Guru 3. The statement in question is:
: Stuart Ferguson (shf@well.UUCP)
: Action by HAVOC (shf@Solar.Stanford.EDU)
How big is sizeof(tplanet)? Manx malloc() wants its argument to be a word, so
if it's bigger than 64K it won't work correctly.
If that's the case, try AllocMem().
--
------------------------------------------------------------------------------
Jim Berry | UUCP:{arizona,decvax,hao}!noao!stsci!berry
Space Telescope Science Institute | ARPA: berry@stsci.edu
Baltimore, Md. 21218 | SPAM: SCIVAX::BERRY, KEPLER::BERRYain@s.cc.purdue.edu (Patrick White) (08/05/88)
In article <386@stsci> berry@stsci.EDU (Jim Berry) writes: >: pplanet = (tplanet *) malloc (sizeof(tplanet)); >: but when it tries to store to the structure, it (sometimes!) crashes with >: Guru 3. > >How big is sizeof(tplanet)? Manx malloc() wants its argument to be a word, so >if it's bigger than 64K it won't work correctly. I've got a program that malloc's more than 64K and it works fine -- in fact, it sort of a version of empire that I've been writing/toying with. Of course, I'm using +pCD options on the compiles. (could it be that malloc expects an *unsigned int* as it's argument and this way, I get to pass it a 32-bit value?) >If that's the case, try AllocMem(). This certainly works, but be *very* sure to free it when you are done (Manx frees any malloc'd memory that you forgot to. -- Pat White ARPA/UUCP: k.cc.purdue.edu!ain BITNET: PATWHITE@PURCCVM PHONE: (317) 743-8421 U.S. Mail: 320 Brown St. apt. 406, West Lafayette, IN 47906
joe@dayton.UUCP (Joseph P. Larson) (08/05/88)
In article <386@stsci> berry@stsci.EDU (Jim Berry) writes: >From article <6711@well.UUCP:, by shf@well.UUCP (Stuart H. Ferguson): >: pplanet = (tplanet *) malloc (sizeof(tplanet)); >: >: but when it tries to store to the structure, it (sometimes!) crashes with >: Guru 3. The statement in question is: >How big is sizeof(tplanet)? Manx malloc() wants its argument to be a word, so >if it's bigger than 64K it won't work correctly. Also, Stuart mentioned he was compiling with +L. Doesn't that mean that Manx will use longs for ints rather than shorts? And if so, doesn't THAT mean that "sizeof(tplanet)" will be a long? So, the question is: what will malloc() do when you pass it a long and it wants a short? Just for safety, how about: pplant = (tplanet *) malloc((short)sizeof(tplanet)); That *should* take care of that. Question: does malloc() want a second argument being the type of memory you want? I don't have my manuals with me and always use AllocMem(). -Joe -- UUCP: rutgers!dayton!joe (Feed my Dayton Hudson Department Store Company ATT : (612) 375-3537 picture Joe Larson/MIS 1060 (standard disclaimer...) collection) 700 on the Mall Mpls, Mn. 55402
joe@dayton.UUCP (Joseph P. Larson) (08/05/88)
>In article <386@stsci> berry@stsci.EDU (Jim Berry) writes: >>From article <6711@well.UUCP:, by shf@well.UUCP (Stuart H. Ferguson): >>How big is sizeof(tplanet)? Manx malloc() wants its argument to be a word, so >>if it's bigger than 64K it won't work correctly. (Hmm. I seem to be verbose on this one....) Stuart mentioned he was compiling with +L. Is he also including the 32-bit libraries? c32.lib and m32.lib instead of c.lib and m.lib? This will make a difference, as well. If compiling with +L, then he has to be extra-careful on passing arguments to the 16-bit libraries to not pass longs.... Just another observation. -J -- UUCP: rutgers!dayton!joe (Feed my Dayton Hudson Department Store Company ATT : (612) 375-3537 picture Joe Larson/MIS 1060 (standard disclaimer...) collection) 700 on the Mall Mpls, Mn. 55402
dillon@CORY.BERKELEY.EDU (Matt Dillon) (08/07/88)
>: pplanet = (tplanet *) malloc (sizeof(tplanet)); > >How big is sizeof(tplanet)? Manx malloc() wants its argument to be a word, so >if it's bigger than 64K it won't work correctly. > >If that's the case, try AllocMem(). Now wait just a moment here. If the original program was written for 32 bit integers, then simply use the 32 bit integer option for Aztec C (+L), and *poof* malloc() takes an int = 32 bits. If the original program was written for 16 bit integers, then the malloc call in the original program was known to take only a word and thus that is NOT the problem. Simply compile without the +L option. -Matt
dillon@CORY.BERKELEY.EDU (Matt Dillon) (08/07/88)
>Also, Stuart mentioned he was compiling with +L. Doesn't that mean that >Manx will use longs for ints rather than shorts? And if so, doesn't THAT >mean that "sizeof(tplanet)" will be a long? So, the question is: what will >malloc() do when you pass it a long and it wants a short? Assuming you LINK with the proper library (c32.lib), malloc WANTS a long. > pplant = (tplanet *) malloc((short)sizeof(tplanet)); The compiler would promptly expand sizeof() backup to a long after chopping the high 16 bits and pass a long. (assuming you are compiling with +L) -Matt
shf@well.UUCP (Stuart H. Ferguson) (08/07/88)
joe@dayton.UUCP (Joseph P. Larson) says: >Stuart mentioned he was compiling with +L. Is he also including the 32-bit >libraries? c32.lib and m32.lib instead of c.lib and m.lib? This will make >a difference [...] Ah. (slightly embarassed) So *that's* what the c & m 32 libraries are for. So now I know. I recompiled with these libraries and it worked fine. Thanx to all who replied. You see, I've never needed to use +L before ... >Just another observation. -J Indeed. You know, that "Conquest" code is some of the worst I've ever seen. It looks like it was ported directly from basic. It's forced me to create some neat tools, however, which will probably make their way out into the world at some point... Which is more than the "Conquest" code should have done. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC (shf@Solar.Stanford.EDU)