Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!apple!agate!dog.ee.lbl.gov!ux5.lbl.gov!beard From: beard@ux5.lbl.gov (Patrick C Beard) Newsgroups: comp.sys.mac.programmer Subject: Re: Function pointers and lack of type conversion in Think C Message-ID: <8209@dog.ee.lbl.gov> Date: 23 Nov 90 09:08:26 GMT References: <29170@boulder.Colorado.EDU> Sender: usenet@dog.ee.lbl.gov Reply-To: beard@ux5.lbl.gov (Patrick C Beard) Organization: Berkeley Systems, Inc. Lines: 32 X-Local-Date: Fri, 23 Nov 90 01:08:26 PST In article hanche@imf.unit.no (Harald Hanche-Olsen) writes: #In article <29170@boulder.Colorado.EDU> pratt@boulder.Colorado.EDU (Jonathan Pratt) writes: # # Not a bug, but a missing feature (that would be nice to have). If you'd # read the TC4 manual, language reference, page 441, you'd see: # # "Prototype arguments which are not associated with a named function are # permitted, but not honored. For example: # # int (*fn)(int n); /* prototype ignored */ " # #Ahh, yes, always RTFM first. I looked but did not find the above #reference. All right, so it's not a bug but just another gotcha. #Meanwhile, is anyone out there knowledgeable enough to tell us whether #a true ANSI compiler must behave the way I had believed it would with #respect to function pointers? If not then perhaps I ought to make a #guest appearance in comp.lang.c or some such place to ask the question #there. I don't know if ANSI C compilers have to support this; however, MPW C++ and I believe all C++ compilers handle this correctly. In fact, MPW C++ even calls function pointers of type pascal with the correct calling conventions! pascal void (*fn)(short x, short y); // pushes x, then y. I assume MPW C supports this as well. -- ------------------------------------------------------------------------------- - Patrick Beard, Macintosh Programmer (beard@lbl.gov) - - Berkeley Systems, Inc. "..............Good day!" - Paul Harvey - -------------------------------------------------------------------------------