home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 October / usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso / std_unix / volume.16 / text0045.txt < prev    next >
Encoding:
Text File  |  1989-08-11  |  3.3 KB  |  65 lines
  1. Posted-From: The MITRE Corp., Bedford, MA
  2. X-Alternate-Route: user%node@mbunix.mitre.org
  3. Cc: std-unix, jsq@longway.tic.com, posix-ada-committee@grebyn.com
  4. From: uunet!aries.mitre.org!emery (David Emery)
  5.  
  6. Shane writes:
  7. >I guess that I may have said something a little strong here.  However,
  8. >I am not ready to retract the statement.  There were many people at
  9. >the Minneapolis meeting last fall who were not at all aquainted with
  10. >the semantics of fundamental parts of Unix.  As an example, I would
  11. >point to the misconception (by all of the group, if I remember
  12. >correctly) that if you call getcwd() with a NULL pointer, and then
  13. >later changed directories with a chdir(), then the string pointed to
  14. >by that previous call would be replaced by the new pathname!  This is
  15. >hardly a full understanding.
  16.  
  17. I don't remember this incident, and I was in Minneapolis last fall.  I
  18. do know that there are places in 1003.1 (but getcwd() is NOT one of
  19. them) where sometimes a call returns the address of memory which is
  20. subject to change (i.e. memory inside the kernal, or whatever).  This
  21. causes us major fits with respect to tasking, so we discussed how to
  22. prevent/avoid/remove this problem.  I also remember some discussions
  23. concerning the behavior of POSIX (not Unix) when NULL was passed as a
  24. parameter to some routines.  This was often (particularly in Draft 12)
  25. not well specified, even as being undefined.  (Incidently, calling
  26. getcwd with a NULL pointer is clearly stated as being undefined in
  27. 1003.1 Drafts 12 and 13.) 
  28.  
  29. We in the Ada community (regardless of Unix-literacy) have a heluva
  30. lot more experience with formal standards documents than the Unix
  31. community.  Consider how most people learn Unix.  It's not by studying
  32. SVID, but rather by learning an implementation.  Often there's
  33. "implicit knowledge" about Unix that is not clear from the POSIX
  34. standard (although 1003.1 Draft 13 was much improved over Draft 12 in
  35. that regard.  There's at least on instance in 1003.2 where I objected
  36. to something in the draft for that very reason.)  Ada has had a
  37. validation suite before there were any implementations; we as a
  38. community have learned a lot about standards and measuring
  39. conformance.  (I can provide a few war stories...)
  40.  
  41. So, my point is this:  I still believe Shane's characterization is
  42. unfair.  What he sees as "lack of understanding" may very well be an
  43. attempt to fully explore the rammifications of the P1003.1 standard,
  44. as opposed to "common knowledge about Unix".  
  45.  
  46. There are times when I think that the Unix community doesn't fully
  47. understand their own semantics.  For instance, in the sample
  48. Language Independent Definition, the type file_descriptor was made an
  49. "opaque" type, one whose representation is not visible.  This won't
  50. work.  In particular, if this type is not an integer, how do you
  51. 'name' file_descriptors that are not stdin, stdout and stderr?
  52. Specifically, what is the 1003.1 meaning of 1003.2 I/O redirection for
  53. FD 7, for instance?  As an active participant in many of these
  54. discussions, I remember all the Unix arcana that wandered around the
  55. 1003.5 group trying to understand what the intended POSIX semantics
  56. for file descriptors are.  We originally proposed that file_descriptor
  57. be an Ada "private" type, but based on our knowledge of Unix, decided
  58. that this would not work.  
  59.  
  60.                 dave emery
  61.                 emery@mitre.org
  62.  
  63. Volume-Number: Volume 16, Number 43
  64.  
  65.