home *** CD-ROM | disk | FTP | other *** search
/ Programmer 7500 / MAX_PROGRAMMERS.iso / PROGRAMS / UTILS / HAMRADIO / TCP90127.ZIP / TCP90127.TXT
Encoding:
Text File  |  1990-09-20  |  4.8 KB  |  124 lines
  1. TCP-Group Digest            Sun,  2 Sep 90       Volume 90 : Issue 127
  2.  
  3. Today's Topics:
  4.                           Clarkson WD driver
  5.                       SMTP implementation ideas
  6.                   Turbo Assembler/Turbo C  question
  7.  
  8. Send Replies or notes for publication to: <TCP-Group@UCSD.Edu>
  9. Send requests of an administrative nature (addition to, deletion from the
  10. distribution list, et al) to: <ListServ@UCSD.Edu>
  11.  
  12. Archives of past issues of the TCP-Group Digest are available
  13. (by FTP only) from UCSD.Edu in directory "mailarchives".
  14. ----------------------------------------------------------------------
  15.  
  16. Date: Sat, 1 Sep 90 13:16:03 PDT
  17. From: Pete Carah <ames!elroy!grian!puffin!pete>
  18. Subject: Clarkson WD driver
  19. To: tcp-group@ucsd.edu
  20.  
  21. I'm trying to get nos 731 running using the Clarkson WD packet driver.
  22. This is on a 286 with the board on irq 2 and all other defaults.
  23.  
  24. The Clarkson driver is the latest one just fetched from sun.soe.clarkson.edu
  25. yesterday.
  26.  
  27. The driver correctly redirects 2 to 9, so it spots the AT bus.
  28.  
  29. PKTSTAT appears to show the right number of packets.
  30.  
  31. My difficulty is that the receive upcall seems to not get called unless
  32. I send a packet, and then only sometimes. (The host has rwhod running so
  33. lots of packets get generated.  My ethernet trace program works fine on
  34. the same AT with the same card, so I'm pretty sure that the card works right.
  35. It uses my own interrupt routine and not the "packet" driver's.)
  36.  
  37. The only peculiarity is that I've compiled the nos using tc++ rather than tc,
  38. with some rearrangement of includes.  Has anyone else used this combination
  39. of driver and compiler?
  40.  
  41. I've tried later versions of nos and they have bugs in the socket code, so
  42. I'm waiting...
  43.  
  44. -- Pete
  45. (pete@puffin.uucp) ...!{elroy.jpl.nasa.gov!grian | hacgate}!puffin!pete
  46.  
  47. ------------------------------
  48.  
  49. Date: 1 Sep 90 11:44 -0700
  50. From: Doug Collinge VE7GNU <djc@samisen@uvicctr.uvic.ca>
  51. Subject: SMTP implementation ideas
  52. To: tcp-group@ucsd.edu
  53.  
  54. >X-Mailer: Mush 6.5.6 (PC R6.3 22-Sep-89)
  55.  
  56. > From: Brian Lloyd <uvicctr!robin.telebit.COM!brian>
  57. > I have been using an SMTP client recently that has a very nice
  58. > characteristic. ...
  59.  
  60. This is fine. But the nice thing about the "backing-off forever" method
  61. is that it has no user-detunable parameters.
  62.  
  63. 73 doug [NO USER SERVICEABLE PARTS INSIDE - WARRANTY VOID IF SEAL IS BROKEN]
  64.  
  65.  
  66. -- 
  67. /\/\/\/\/\/
  68. Doug Collinge,    first try: collinge@uvicctr.uvic.ca
  69.         then try:  samisen!djc@uvicctr.uvic.ca
  70. VE7GNU        VE7GNU@VE7GNU.#VIC.BC.CAN.NA
  71.         Victoria, BC, Canada
  72.  
  73. ------------------------------
  74.  
  75. Date: Sun, 2 Sep 90 05:12:05 UTC
  76. From: karn@ka9q.bellcore.com (Phil Karn)
  77. Subject: Turbo Assembler/Turbo C  question
  78. To: shep@allspice.lcs.mit.edu, tcp-group@ucsd.edu
  79.  
  80. Tim,
  81.  
  82. You're quite right -- the arguments don't match, and they should.  But
  83. things still work because there are no byte-wide stack operations on the
  84. 8088; calling a function with a character argument still pushes two bytes on
  85. the stack.
  86.  
  87. The main reason I have recently gone to using ints (or shorts) in place of
  88. some of the chars in NOS is to avoid the $#@!! sign-extension problems that
  89. can occur since Turbo-C chars are signed by default. This problem has become
  90. much worse since ANSI-C came out, since type promotion is no longer
  91. "unsigned preserving" as it was in K&R C.
  92.  
  93. I'll probably go through the code and try to clean up little nits like
  94. this. Ordinarily I find them through the type-checking that the compiler
  95. provides, but there is unfortunately no type-checking against assembler
  96. subroutines.
  97.  
  98. Tangential flame on:
  99.  
  100. In my opinion, the unspecified signed-ness of chars is probably the most
  101. serious design mistake in the C language. Other mistakes, in my opinion,
  102. include ANSI's changes in type promotion I just mentioned, the unexpectedly
  103. low precedences of the & and | operators, the default signed nature of
  104. integers, and the use of an undeclared function causing it to be declared
  105. 'int' by default.  Chars and ints should both be unsigned by default,
  106. the & and | operators should have the same precedence as the binary arithmetic
  107. operators, and all functions should have to be declared before being called.
  108.  
  109. I understand that there were good reasons at the time for some of these
  110. design choices. Chars were left unspecified because they were inherently
  111. signed on the PDP-11 (where C spent most of its childhood) and unsigned
  112. elsewhere.  And the & and | operator precedences are as low as they are
  113. because there were no && and || operators originally in C and & and | were
  114. used instead. I understand that there were as many as 30 programmers already
  115. using C when the && and || operators were introduced, so they couldn't
  116. possibly make such a drastic change to such a widely used language...
  117.  
  118. Phil
  119.  
  120. ------------------------------
  121.  
  122. End of TCP-Group Digest
  123. ******************************
  124.