dlarson@blake.acs.washington.edu (Dale Larson) (10/25/89)
/* sometimes I forget to feed the line-eater, but please don't quote that */
Here are the replies I've recieved so far in regards to Port vs. MsgPort:
-=-=-=-=-=-=-=-=-=-=-=--
From dillon@postgres.Berkeley.EDU Mon Oct 23 23:32:53 1989
I've never heard of a 'Port' and suspect it is probably a
typedef to a MsgPort. I usually typedef MsgPort to PORT.
-Matt
-=-=-=-=-=-=-=-=-=-=-=-=-
From rosenber@ra.abo.fi Tue Oct 24 00:07:28 1989
Many C compilers allow you to use structures names that are not
defined so struct MsgPtr *port; will do or: struct Port *port; even if
the structure tags doesn't exist.
Ofcourse if you try to reference fields in these structures you'll get
an error message.
So the use of struct Port may come from sloppy code.
Lattice has an option that gives errors for undefined structure tags.
--------
Robin Rosenberg
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
me:
Not only is Port and MsgPort confused, but so is CreateStdIO() and
CreateExtIO(). Again, I can find no reference to CreateExtIO() in
the AutoDocs. I guess this is one of the problems people are refering
to when they say the RKM's suck. The check is in the mail to Rob Peck
for _Programmer's Guide_, so I will hopefully have some more useful
documentation. I am sure that the problems with the RKM's are a result
of very early software and too too little time, but it would be nice
if C/A would have put a little bit of that $15 mil from ads into new docs
so that more programmers can understand better so that we can all see
fewer Guru's!!! (And I wish they would send extra copies of all docs
to the programmers at WP :-)
Has any one compiled a list of errata to the RKM's??? I would very much
like to have such a list!!!
If no such list has been made, here is a start:
In the pages below, all references to "struct Port" should apparently be
changed to "struct MsgPort" and all references to "CreateStdIO()" should
become "CreateExtIO()"
_RKM: Libraries and Devices_ page 277:
struct IOStdReq *consoleWriteMsg;/* I/O request block pointer */
struct Port *consoleWritePort; /* a port at which to recieve replies */
...
consoleWriteMsg = CreateStdIO(consoleWritePort);
(same on page 288, but for consoleReadPort)
Other pages with the Port instead of MsgPort:
264, 384, 402, others I've missed :-)
--
A lack of prior planning on the part of any programmer
always constitutes an emergency.
Digital Teddy Bear dlarson@blake.acs.washington.eduahh@glyph.UUCP (Andy Heffernan) (10/26/89)
In article <4186@blake.acs.washington.edu> dlarson@blake.acs.washington.edu (Dale Larson) writes: [ munch ] >Not only is Port and MsgPort confused, but so is CreateStdIO() and >CreateExtIO(). Again, I can find no reference to CreateExtIO() in >the AutoDocs. I guess this is one of the problems people are refering Gee, my crummy old 1.2 autodocs have CreateStdIO() and CreateExtIO(). Look in the exec_support section. CreateStdIO() allocates enough memory for a IOStdReq structure and initializes it (appropriate for console.device manipulations, for example), while CreateExtIO() allocates the amount of memory you specify and initializes it (good for serial.device's IOExtSer). I've only seen the newer autodoc-generated manual once (and that was probably a year ago), but the two functions mentioned above are given in the 1.1 Addison-Wesley Exec manual, in Appendix B. They live in amiga.lib (still?) >In the pages below, all references to "struct Port" should apparently be >changed to "struct MsgPort" Ack, yes. > and all references to "CreateStdIO()" should >become "CreateExtIO()" Ack, no. -- ------------------------------------------------------------------------- Andy Heffernan uunet!glyph!ahh "Today is the first day of the rest of your long, miserable life" -- Dix.
dlarson@blake.acs.washington.edu (Dale Larson) (10/26/89)
In article <488@glyph.UUCP> ahh@glyph.UUCP (Andy Heffernan) writes: >In article <4186@blake.acs.washington.edu> dlarson@blake.acs.washington.edu (Dale Larson) writes: >>Again, I can find no reference to CreateExtIO() in >>the AutoDocs. I guess this is one of the problems people are refering OOPS! I meant to say that I can find no reference to CreateStdIO(), of course I can find reference to CreateExtIO()!!! (right in the index even :-) >Gee, my crummy old 1.2 autodocs have CreateStdIO() and CreateExtIO(). >Look in the exec_support section. CreateStdIO() isn't in the 1.3 autodocs, at least, not in the function index (unless out of place alphabetically :-) >>and all references to "CreateStdIO()" should become "CreateExtIO()" > >Ack, no. Does this mean my 1.3 autodocs are buggy? -- A lack of prior planning on the part of any programmer always constitutes an emergency. Digital Teddy Bear dlarson@blake.acs.washington.edu
mks@cbmvax.UUCP (Michael Sinz - CATS) (11/07/89)
In article <4203@blake.acs.washington.edu> dlarson@blake.acs.washington.edu (Dale Larson) writes: >In article <488@glyph.UUCP> ahh@glyph.UUCP (Andy Heffernan) writes: >>In article <4186@blake.acs.washington.edu> dlarson@blake.acs.washington.edu (Dale Larson) writes: >>>Again, I can find no reference to CreateExtIO() in >>>the AutoDocs. I guess this is one of the problems people are refering > >OOPS! I meant to say that I can find no reference to CreateStdIO(), >of course I can find reference to CreateExtIO()!!! (right in the >index even :-) > >>Gee, my crummy old 1.2 autodocs have CreateStdIO() and CreateExtIO(). >>Look in the exec_support section. > >CreateStdIO() isn't in the 1.3 autodocs, at least, not in the function >index (unless out of place alphabetically :-) We are trying to discurage the use of CreateStdIO(). Since both of these are linker libraries, this is no real problem. Also, CreateStdIO() will now just do a CreateExtIO() with sizeof(struct IOStdReq) DeleteStdReq() will also now just call DeleteExtReq() and since the delete routine knows how big the request is, it will correctly free the memory. >Does this mean my 1.3 autodocs are buggy? No, this does not, but there is no such thing as bug-free system documentation. >-- > A lack of prior planning on the part of any programmer > always constitutes an emergency. > > Digital Teddy Bear dlarson@blake.acs.washington.edu /----------------------------------------------------------------------\ | /// Michael Sinz -- CATS/Amiga Software Engineer | | /// PHONE 215-431-9422 UUCP ( uunet | rutgers ) !cbmvax!mks | | /// | |\\\/// When people are free to do as they please, | | \XX/ they usually imitate each other. | \----------------------------------------------------------------------/