home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v9 / text0041.txt < prev    next >
Encoding:
Text File  |  1987-06-30  |  6.1 KB  |  121 lines
  1. >From: seismo!gatech!hpcnof!hpfcla!hpfcdc!rml (Bob Lenk)
  2. >
  3. >> From: cbosgd!mark@seismo.css.gov (Mark Horton)
  4. >> 
  5. >> While P.1003 does not restrict implementations to SYS_NMLN=9 (including
  6. >> the null) it requires that all 5 fields support the full length.
  7. >> I don't know of any way to increase SYS_NMLN while maintaining binary
  8. >> compatibility with older programs, which is a typical requirement.
  9. >
  10. >Since the publication of the trial use standard, the working group has
  11. >agreed to drop the constant SYS_NMLN and any requirement that all
  12. >five fields be the same length.  All fields are now specified simply
  13. >as null-terminated character arrays.
  14.  
  15. Does the new standard still allow an implementation whose nodename field
  16. holds only 9 characters?  If so, I predict that the binary compatibility
  17. issue will be so overwhelming that vendors will not increase this size,
  18. and systems will continue to be unable to handle networks properly.
  19.  
  20. > Increasing the length can still cause binary compatibility problems, but
  21. > there are (ugly) ways of dealing with binary compatibility.
  22.  
  23. > From: guy%gorodish@Sun.COM (Guy Harris)
  24.  
  25. > Most, if not all, implementations based on UNIX could just assign a
  26. > new system call number to a new improved "uname" and leave the old
  27. > one around with its old number for binary compatibility.  You can
  28. > write a library that contains a "uname" that uses the old call, or
  29. > uses the new call and throws away the extra characters.
  30.  
  31. Generally, you have to be upward compatible in three ways:
  32. (1) source code compatible: easy, just fix <utsname.h>
  33. (2) binary a.out compatible: ugly but easy, change the system call number
  34. (3) binary .o compatible: oops - how do you handle this one?
  35.     An existing library libfoo.a can call uname.  You relink the
  36.     old library with the new libc, getting the new system call
  37.     number with the old include file.  I don't see any way to tell
  38.     old .o's from new .o's, since uname does not pass the size
  39.     of the structure or any other distinguishing information.
  40.     (You could change the .o format/version, and teach the linker to know
  41.     about uname and which .o format/version gets which version of uname,
  42.     but that's a pretty horrible thought.)
  43.  
  44. >From: seismo!gatech!hpcnof!hpfcla!hpfcdc!rml (Bob Lenk)
  45.  
  46. >If we use such an approach, we still need to specify a symbolic constant
  47. >(in <limits.h>) for the maximum length of a hostname on an
  48. >implementation, so that applications don't need to deal with having
  49. >truncated names returned to them.
  50.  
  51. Of course - like any array, you should specify a minimum maximum,
  52. and put the size in <limits.h>.  (Although Bob Lenk's note sounds like
  53. the new version of uname doesn't have sizes for the 5 arrays, I hope
  54. I just misunderstand what it really says.)  One nice thing about
  55. gethostbyname, however, is that, since it passes the size at runtime,
  56. it doesn't really matter what the minimum maximum is, except that if
  57. system or user specifies a small number like 8, you'll lose information.
  58.  
  59. >Uname handles this by the inclusion
  60. >of the string within a structure.  Given that, the only difference from
  61. >uname is the existence of other fields.  For binary compatibilty, I
  62. >don't see much difference between an implementation having two calls
  63. >both called "uname" or one called "uname" and the other called
  64. >"gethostname", which return names of different lengths.
  65.  
  66. There are several differences:
  67.  
  68. (1) uname has 4 other fields, of marginal use for inclusion in POSIX.
  69.     I doubt any implementation would provide a call called "uname"
  70.     that supports only one field, even if POSIX allowed it.
  71.  
  72. (2) uname does not pass the size of the structure as another parameter.
  73.  
  74. (3) the traditional (and easily compatible) implementation of uname
  75.     only allows 8 chars in the node name.  Since SYS_NMLN is new to
  76.     POSIX, there is a lot of code out there that has the number 8
  77.     hardwired into it, especially in buffers used to store the name.
  78.     My SVr3 manual still tells me that the fields are 9 bytes long,
  79.     and I'll bet lots of programmers believe that instead of checking
  80.     the SVID and POSIX standards.
  81.  
  82. (4) Because of (1) and (2), there is no easy way to grow the length
  83.     of any one field without superhuman binary compatibility efforts.
  84.     Ditto for adding new fields.  Any multi-field table lookup system
  85.     call ought to be extensible, which means it ought to pass info at
  86.     runtime about which items it wants, and the sizes of the buffers
  87.     provided to copy these items into.
  88.  
  89. I as a user would be satisfied if you were to require that the uname
  90. call support at least 256 characters of node name (and, of course, that
  91. the actual size be in <limits.h>.)  I almost said 64 characters, but
  92. then I thought of OSI and wanted to be safe. I could immediately write
  93. code to implement gethostname in terms of uname.  But the result would
  94. be awfully unclean for the users (having to declare a structure and copy,
  95. having to fix existing code not to know the number 8) and would be an
  96. incredible mess for the people stuck supporting binary compatibility.  (Let's
  97. see now, the C compiler is unbundled from the kernel, so we have to make
  98. sure we put out a new ld in the right places, and have to ensure that
  99. <utsname.h> is the new version if you have the new loader and the new
  100. kernel, and ...  Do we want to require this in a standard without someone
  101. implementing it first to find the gotchas?)
  102.  
  103. The current uname is inadequate for modern networks.  There is no way
  104. to make it adequate without requiring that nodename be made bigger.
  105. There is no way to make the nodename bigger without considerable
  106. uglyness and kludging, some of which will be visible to the users.
  107.  
  108. It would be far cleaner and simpler, with far less upheaval among
  109. implementors and users, to put in gethostname, which does exactly
  110. what is needed, and is already present in 4.2BSD and AT&T's WIN/3B
  111. TCP/IP package.  uname could continue to exist, in its old form, for
  112. upward compatibility, but it would return a truncated host name
  113. (or else the above superhuman efforts could be undertaken by the
  114. system developers to return a full host name.)  I see no reason to
  115. require these superhuman efforts with ugly results in POSIX.
  116.  
  117.     Mark Horton
  118.  
  119. Volume-Number: Volume 9, Number 42
  120.  
  121.