strasser@murdu.OZ (Mike Strasser) (09/09/88)
A month or so ago I posted a query about a program I'd ported to LSC
which had run extensively under VAX/VMS, Unix and MS-DOS, and which was
hanging. Today I've had more time to check it out, and it seems that
malloc() is returning nonsense.
It is called and the result cast to a pointer to a structure I use:
Sp = (Species *) malloc( sizeof( Species ) );
I check for a NULL return, which does not happen. Instead, Sp is loaded
the value 0x00000003 every time on repeated calls! I'm assuming that the
statement:
printf( "Sp is %08X\n", (unsigned long) Sp );
is OK as a way of checking the address (yes, I'm still using stdio).
00000003 is not a legal address is it? malloc() certainly shouldn't be
returning the same value on repeated calls (no use of free() in
between)? I have put in complete prototype checking (although in LSC
2.15 I had to write full prototypes for the library functions so the
compiler would pass them!) but it has not helped.
I still only have LSC 2.15 (waiting for 3.0).
Any ideas? Have I missed something?
---------------------------------------------------------------------------
Mike Strasser ACSnet, CSnet: strasser@murdu.oz
Internet: strasser%murdu.oz@uunet.uu.net
Forestry Section
University of Melbourne
Creswick, Victoria. 3363 Phone: (053) 45 2405
A u s t r a l i a +61 53 45 2405
---------------------------------------------------------------------------singer@endor.harvard.edu (Rich Siegel) (09/11/88)
In article <1451@murdu.OZ> strasser@munnari.UUCP (Mike Strasser) writes: > >It is called and the result cast to a pointer to a structure I use: > > Sp = (Species *) malloc( sizeof( Species ) ); > >I check for a NULL return, which does not happen. Instead, Sp is loaded >the value 0x00000003 every time on repeated calls! I'm assuming that the You probably need to pre-declare malloc(): void * malloc()); before you call it. Otherwise, the compiler will assume that malloc() returns an int instead of a pointer-type, and only that int gets assigned to your pointer variable. Odds are, the high word if the result is a 3.... R. Rich Siegel Staff Software Developer THINK Technologies Division, Symantec Corp. Internet: singer@endor.harvard.edu UUCP: ..harvard!endor!singer Phone: (617) 275-4800 x305 Any opinions stated in this article do not necessarily reflect the views or policies of Symantec Corporation or its employees.
strasser@murdu.OZ (Mike Strasser) (09/11/88)
Thanks to the people who responded to my problem with malloc(). I had a
number of bugs in the program (including writing much information to
an unintialized output stream because I accidentally deleted the
initialization code!!), but malloc() did need to be declared, and using
"%lx" instead of "%x" in my printf statement showed that the high-word
of the addresses was indeed 3!
Now I just need to trim the number of floating point calls so the thing
doesn't run so s--l--o--w. It (a forest modelling program) has to run
on SEs for a student prac, so I don't have the luxury of using our Mac
II all the time.
---------------------------------------------------------------------------
Mike Strasser ACSnet, CSnet: strasser@murdu.oz
Internet: strasser%murdu.oz@uunet.uu.net
Forestry Section
University of Melbourne
Creswick, Victoria. 3363 Phone: (053) 45 2405
A u s t r a l i a +61 53 45 2405
---------------------------------------------------------------------------simon@alberta.UUCP (Simon Tortike) (09/12/88)
I am writing an application that requires me to change a string into a float or double number. The input is already partly filtered (a filterproc in a modal dialog) but I still need to check the exponentiation, etc. K&R (2nd. ed) document `double strtod(const char *s, char **endp)' as part of the header file <stdlib.h>, which returns information in *endp whether the entire string was converted. In my case, I wish to reject the number if this is so. `atof(s)' only returns the converted number up to the first invalid character, with no info. about the conversion. However, `strtod' is undocumented in my versions of LSC (2.15) (3.0 upgrade on order for over two months ago: I'd buy it from MacWarehouse now but Symantec have our cheque) and MPW C (v2.0.2). Could someone suggest what else I could try short of writing a scanning routine of my own? (Meanwhile, I suppose I shall!) ------------------- Simon Tortike, Department of Mining, Metallurgical and Petroleum Engineering, The University of Alberta, Edmonton, AB, CANADA T6G 2G6. simon@alberta.uucp | AGT: 403/432-3338 | stortike@ualtavm.bitnet
kah120@ihlpe.ATT.COM (Ken Heitke) (09/12/88)
In article <1451@murdu.OZ>, strasser@murdu.OZ (Mike Strasser) writes: > A month or so ago I posted a query about a program I'd ported to LSC > which had run extensively under VAX/VMS, Unix and MS-DOS, and which was > hanging. Today I've had more time to check it out, and it seems that > malloc() is returning nonsense. > > It is called and the result cast to a pointer to a structure I use: > > Sp = (Species *) malloc( sizeof( Species ) ); > > I check for a NULL return, which does not happen. Instead, Sp is loaded > the value 0x00000003 every time on repeated calls! I'm assuming that the > statement: > > printf( "Sp is %08X\n", (unsigned long) Sp ); I don't know if this is the same problem I struggled with over the weekend but have you included Storage.h or declared malloc to be a function which returns a pointer (i.e. void *malloc()). This declaration exists in Storage.h and without it the compiler by defaults thinks malloc is returning an int and you basically only get 16 bits of your pointer (since pointers and ints are different sizes). I really got nailed good by this because for most UNIX programs one never declares malloc because you have to cast it anyways. LSC requires that special include file which you doesn't exist in UNIX land. BTW I find using printf ("Ptr = %lX\n", Sp); to work. I think in your print statement the printf assumes it is reading an int and just pads it with zeros to get 8 digits. Ken Heitke att!ihlpe!kah120 is