home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.26 / text0003.txt < prev    next >
Encoding:
Text File  |  1992-02-21  |  4.1 KB  |  79 lines
  1. Submitted-by: jason@cnd.hp.com (Jason Zions)
  2.  
  3. Doug Gwyn said:
  4.  
  5. >No, what I was really
  6. >complaining about is the large amount of committee invention in 1003.2,
  7. >especially such atrocities as "c89", the regular expression mess, and a
  8. >rash of commands and options not previously implemented in ANY version of
  9. >UNIX.
  10.  
  11. In another message, someone else had pleaded that POSIX standardizers get
  12. their head out of the clouds and actually standardize what had already been
  13. implemented. (I'll ignore the implied insult that most POSIX writers are not
  14. in fact implementors; direct contradiction with reality.)
  15.  
  16. The "c89 atrocity" to which Doug refers is a perfect example of the kind of
  17. invention made *necessary* by *existing implementations*.
  18.  
  19. The typical C compiler has between 30 and 60 options, using most of the
  20. lower- and upper-case letters. If one were to take the union of all features
  21. provided by the top 5 non-commonly-derived implementations, one might find
  22. around 60 unique options implemented by two or more of those five; if one
  23. were to be selective and try to identify the options which represent the
  24. concensus of implementations, one might find, oh, 40 or so.
  25.  
  26. Now, suppose vendor A has implemented one of those options, and it is
  27. invoked by using the -P option. Similarly, vendor B's compiler implements
  28. the same option, but used -S for it, and put another of the 40-odd concensus
  29. options on -P. Tell me, which option should the standard "cc" turn on when
  30. the -P option is used? The one vendor A put there, or the one vendor B put
  31. there? Either way, shell scripts already existing on machines built by A or
  32. B will suddenly, and silently, stop working correctly. There's no way for a
  33. vendor to offer a graceful cut-over period; when a user rolls to the
  34. 1003.2-conforming release, all those makefiles and shell scripts which
  35. invoke cc with the changed options will break.
  36.  
  37. The "c89" solution, ugly as it may be, offers vendors, and users, an
  38. opportunity to gracefully shift over to the new, standard, option set. A
  39. vendor will continue to provide the same "cc" driver they provide today,
  40. with the same non-standardized set of options. At the same time, the vendor
  41. would also provide a "c89" driver which understood the new, standard, option
  42. set. Makefiles and shell scripts could be converted at leisure, and
  43. converted and unconverted scripts could coexist on the same system. Two or
  44. three releases into the future, a vendor could obsolete the old option set
  45. for "cc" and make that command a synonym for c89, if they so chose.
  46.  
  47. At the same time, the c89 option space is cleaned up and more rigorously
  48. controlled; this means that new standard options can be added in the future
  49. without needing to go through this mess again. 
  50.  
  51. The only thing which is perhaps atrocious about "c89" is the name itself. It
  52. had to be different from "cc"; what would you have chosen?
  53.  
  54. As regards the "commands and options not previously implemented", many of
  55. them are directly implied by the stuff in 1003.1 (the pathconf-related shell
  56. commands come to mind). If those kinds of changes were important enough to
  57. application portability to be put in 1003.1, why would similar changes not
  58. be needed to help ensure script portability?
  59.  
  60. The "regular expression mess" was similar to the c89 problem, but worse;
  61. they couldn't change the command names to separate the regexp letter names.
  62. More than that, regexp's as usually implemented were hopelessly
  63. ethnocentric; changing languages was impossible. All POSIX standards have an
  64. *explicit* goal of being International (ISO) standards; non-English support
  65. is *required* to meet that goal, as ISO JTC1/SC22/WG15 has made abundantly
  66. clear. Given the fact that the union of common implementations resulted in
  67. most of the useable characters being given conflicting meanings, and that a
  68. "good" standard causes equal pain for everyone instead of favoring one of
  69. the implementations over others, how would *you* have resolved it?
  70.  
  71. Doug, you mentioned your original proposal to 1003.2 all those years ago.
  72. How did that proposal address overlap of options in the most common
  73. implementations, hopeless English-centrism, and the like?
  74.  
  75. Jason Zions
  76.  
  77. Volume-Number: Volume 26, Number 4
  78.  
  79.