home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.28 / text0006.txt < prev    next >
Encoding:
Text File  |  1992-08-17  |  5.1 KB  |  97 lines
  1. Submitted-by: gnu@toad.com (John Gilmore)
  2.  
  3. [ This originallly appeared in comp.std.c.  However, I think some of
  4.   the points John is tryring to make are valid criticisms applicable
  5.   to POSIX as well as ANSI C.  Most followup's should probably go
  6.   to comp.std.c; however, it is entirely possible to make comments
  7.   relevent to this group, so I've not put in a Followup-To: line.
  8.   Please use your judgement -- mod ]
  9.  
  10. It seems to me that the ANSI C committee overstepped the boundaries of
  11. `prior art', producing scores of needless incompatabilities.  And they
  12. plan to do it again soon.
  13.  
  14. My company works on a compiler.  This compiler runs on a large variety
  15. of host systems.  It cannot control the include files on those host
  16. systems.  The ANSI C `model' was of a unified compiler and include
  17. files and libraries.  Unfortunately, the market does not fit that
  18. model.  We have to interoperate with the host-supplied include files
  19. and libraries.
  20.  
  21. We now have a 640-line shell script that fixes up the include files on
  22. a bunch of these host systems.  The problems we run into are utterly
  23. trivial.  The question of whether memcpy returns a char * or a void *.
  24. Whether the abort function `returns' int or void, even though it
  25. doesn't return.  Whether arguments to stdio functions include the const
  26. qualifier.  Each of these is an issue on a different host system.
  27. There is no prayer of getting more than a hundred compilers to agree on
  28. all these fiddly details.  Neither the compiler writer, nor the library
  29. author, nor the user cares one whit about this stuff.  But because of
  30. ANSI C, we are all stuck with trying to make it consistent.  Because if
  31. we don't, our programs don't compile, due to conflicting declarations.
  32. Because of ANSI C.
  33.  
  34. It's been possible to write portable programs for a long time.  Once
  35. ANSI C appeared, it became harder to write portable programs.  It is
  36. infected with the "I'm the only variant of C in existence" disease even
  37. worse than most vendors' C implementations.  And the Committee felt
  38. free to change all sorts of things (like the types in the above
  39. paragraph), without regard for the impact it has on users.  Vendors, at
  40. least, have to stay compatible with other major vendors; the Sun-1
  41. compiler had to compile 'most anything you could throw at a Vax, or Sun
  42. wouldn't have survived.  The ANSI C committee seems to be more
  43. insulated from the results of its decisions.  This needs changing.
  44.  
  45. In a portable program, how can I declare `abort'?  Old compilers don't
  46. have <stdlib.h>, so I can't just include that, or I'll get a
  47. compile-time error.  Some old compilers consider it void, others
  48. consider it int.  At link time nobody will care, so I could just
  49. explicitly declare it either way.  But if for some reason <stdlib.h>
  50. *does* get included, perhaps through a host-dependent config file, and
  51. you declared it backwards from the way <stdlib.h> declared it, your
  52. program won't compile.  On SunOS 4.1.1, which is a non-ANSI system,
  53. <stdlib.h> declares abort `extern int abort (/* void */);'.  (Non-ANSI
  54. systems are free to do things like this.  It doesn't violate any
  55. standards.)  The solution we adopted is to declare abort in the host-
  56. dependent configuration file.  It is *one more thing* that we have to
  57. configure on a host-by-host basis.  Our program is more complicated,
  58. harder to understand, and harder to port.  Because of ANSI C.
  59.  
  60. The answer `Just wait til everything is ANSI C' is a symptom of
  61. infection with the aforementioned disease.  What if we want to write
  62. programs *now*?  Also, the ANSI C committee wants to start revising the
  63. C standard again.  So even if you waited til everything was ANSI C,
  64. there will soon be two of them, and you'll be back fiddling with
  65. bullshit details just to get working programs to compile.
  66.  
  67. They've started by changing the paragraph numbering just to get us
  68. warmed up.  And they're throwing away the Rationale because too many
  69. people could follow the deliberations.  Obscure prescriptions in the
  70. third person are always easier to defend than `We did it this way
  71. because ... '.
  72.  
  73. Now they want to `track' what some ISO committee is doing to C.  We
  74. already suffered the first abortion produced thereby -- trigraphs.  The
  75. next plan is to rewrite all the multi-byte character functions.  We
  76. clearly didn't have enough practical experience with them (if they need
  77. changing so soon), and they don't belong in the standard anyway.  So
  78. let's change 'em, and force all the vendors to supply the new ones!
  79.  
  80. Somehow the Committee has the idea that if a good idea doesn't make it
  81. into the standard, it won't be adopted, and that if a bad idea makes it
  82. into the standard, it doesn't matter anyway; it can be changed later.
  83.  
  84. I'll tell them what matters.  What matters is stability.  We have all
  85. the turmoil and all the good ideas we need without their help.
  86. Standards exist to create stability.  I'd be glad to throw the ANSI C
  87. committee a retirement party, if they won't ever meet again for the
  88. next ten years.  I'm serious.
  89. -- 
  90. John Gilmore   {sun,uunet,pyramid}!hoptoad!gnu   gnu@toad.com   gnu@cygnus.com
  91. "It isn't given to us to know those rare moments when people
  92.  are wide open and the lightest touch can wither or heal."
  93.  
  94.  
  95. Volume-Number: Volume 28, Number 7
  96.  
  97.