home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.26 / text0027.txt < prev    next >
Encoding:
Text File  |  1992-02-21  |  1.5 KB  |  36 lines
  1. Submitted-by: brnstnd@KRAMDEN.ACF.NYU.EDU (Dan Bernstein)
  2.  
  3. Bob Lenk writes:
  4. > In article <1991Nov21.235529.9196@uunet.uu.net> gwyn@smoke.brl.mil (Doug Gwyn) writes:
  5. > >    cc -Dmacrostufff -Iheaderdir -c -O foo.c bar.o mylib.a -lX
  6. > > The requirement that this invocation (when -I etc. aren't being used)
  7. > > obtain a C implementation that conforms to the C standard could be left
  8. > > as a separate specification, not necessarily required for 1003.2 proper.
  9. > Then what use would the 1003.2 spec be?
  10.  
  11. It would document what UNIX systems do. Why are you trying to mandate
  12. particular standards of quality? Just because you think high-quality cc
  13. implementations should compile ANSI C is no reason to require everyone
  14. to come up to that level of quality.
  15.  
  16. > An application (script/makefile)
  17. > using it couldn't depend on it compiling standard C, or K&R C, or 6th
  18. > edition C, or perhaps even Cobol.
  19.  
  20. Don't you trust the market to do *anything*? If a vendor markets a UNIX
  21. system where cc compiles Cobol, it won't last too long. (Well, unless
  22. it's IBM.) It's not a disaster that cc doesn't always support ANSI C:
  23. that's *how the world works*! People still manage to write portable
  24. code.
  25.  
  26. POSIX seems to have decided that portable applications *need* cc (or
  27. c89, whatever) to compile ANSI C. Why? On what basis was it decided that
  28. this area needed standardization? The market certainly hasn't made the
  29. same decision. Have you ever considered erring on the side of caution?
  30.  
  31. ---Dan
  32.  
  33.  
  34. Volume-Number: Volume 26, Number 28
  35.  
  36.