home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / mod.std.unix.v9 / text0029.txt < prev    next >
Encoding:
Internet Message Format  |  1987-06-30  |  2.1 KB

  1. From: seismo!gatech!hpcnof!hpfcla!hpfcdc!rml (Bob Lenk)
  2. Date: Thu, 8 Jan 87 20:20:47 mst
  3.  
  4. > From: cbosgd!mark@seismo.css.gov (Mark Horton)
  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.  Increasing the length can still
  14. cause binary compatibility problems, but there are (ugly) ways of
  15. dealing with binary compatibility.
  16.  
  17. > I am also unaware of any application that makes use of the other four
  18. > fields.
  19.  
  20. I can imagine applications using the fields in some type of reports,
  21. but I don't know of any portable applications which use them, or of
  22. any strong reason why they are needed.
  23.  
  24. > Wouldn't it make more sense to standardize on a simple long character
  25. > string for the node name?  Assuming that OSI names can somehow be
  26. > encoded as character strings (a fairly safe assumption, I think)
  27. > this ought to handle all the cases.  The 4.2BSD gethostname function,
  28. > which passes the length of the buffer:
  29. >     gethostname(buffer, bufferlen)
  30. >     char *buffer;
  31. >     int bufferlen;
  32. > seems perfectly suited to this problem.
  33.  
  34. If we use such an approach, we still need to specify a symbolic constant
  35. (in <limits.h>) for the maximum length of a hostname on an
  36. implementation, so that applications don't need to deal with having
  37. truncated names returned to them.  Uname handles this by the inclusion
  38. of the string within a structure.  Given that, the only difference from
  39. uname is the existence of other fields.  For binary compatibilty, I
  40. don't see much difference between an implementation having two calls
  41. both called "uname" or one called "uname" and the other called
  42. "gethostname", which return names of different lengths.
  43.  
  44.         Bob Lenk
  45.         {ihnp4, hplabs}!hpfcla!rml
  46.  
  47. Volume-Number: Volume 9, Number 30
  48.  
  49.