home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / vms / 20622 < prev    next >
Encoding:
Internet Message Format  |  1993-01-08  |  3.3 KB
  1. Path: sparky!uunet!haven.umd.edu!darwin.sura.net!sgiblab!troi!steve
  2. From: steve@dbaccess.com (Steve Suttles)
  3. Newsgroups: comp.os.vms
  4. Subject: Re: VAX C header file standards?
  5. Message-ID: <136@mccoy.dbaccess.com>
  6. Date: 8 Jan 93 23:26:29 GMT
  7. References: <1993Jan7.224528.13810@news2.cis.umn.edu>
  8. Organization: Cross Access Corp., Santa Clara, CA
  9. Lines: 57
  10. X-Newsreader: Tin 1.1 PL4
  11.  
  12. rao@moose.cccs.umn.edu (Rao Akella) writes:
  13. : 
  14. : Are there any standards for VAX C header files?  How does Digital decide what
  15. : definition goes in which file?
  16.  
  17. On a case-by-case basis.  Usually, it is pretty obvious.
  18. : 
  19. : For example, in V3.1 (-051, to be precise), the definition of caddr_t ("typedef
  20. : char * caddr_t;") is present in both DECW$INCLUDE:XOS.H and XRESOURCE.H.  In
  21. : V3.2 (-044), the XOS.H definition was dropped.  I'm feeling slightly bummed
  22. : about this because I recently made Gnu Xchess available for anon ftp at my
  23. : site, and I've since been informed that while V3.1 compiles Xchess correctly,
  24. : V3.2 returns compilation errors (because Xchess includes XOS.H but not
  25. : XRESOURCE.H).
  26.  
  27. Cite the compiler version.  Test new versions.  You might be able to
  28. be compatible with both by including headers which are "extra" for some
  29. circumstances.
  30.  
  31. : 
  32. : Shouldn't all existing definitions be left in there in the interest of upward
  33. : compatibility?  Or was there a good reason for Digital to change the header
  34. : files in between upgrades?
  35. : 
  36. Perhaps...but you wouldn't like it.  The reason they changed is for ANSI
  37. compatibility (well, approaching ANSI).  In order to meet both goals, they
  38. would have to #ifdef on some indication that you were using/not_using ANSI
  39. compliant mode.  The size of the headers would double, as would their
  40. complexity (which -does- have an effect--compile time and user comprehension).
  41.  
  42. The "good" news is you probably won't have to deal with this again; VAX C
  43. gets virtually no support, since all the money is on DEC C.  Of course, this
  44. is the bad news too--VAX C will fall off in popularity when there is any
  45. acceptable alternative (if you ported to VAX C, you already know that large
  46. parts of the runtime library--forget header files--are brain dead).
  47.  
  48. sas
  49.  
  50. PS:  DEC in no way approves of my opinion of VAX C.  I do not approve of their
  51. opinion, so I guess that's fair.  They must think it's fair too, because they
  52. still won't fix the parts that are broken.  Yes, I have a list, and yes, I gave
  53. it to them.  The part that really bothers me is that I'm forced by circumstance
  54. to use and recommend VAX C, and that most of the problems could be fixed within
  55. the runtime libary, and those that can't, can be worked around...but even this
  56. information can't get distributed.
  57.  
  58. For the record, just to be fair, the compiler is not at fault.  The problem
  59. lies entirely within the runtime library, distributed with and as a part of
  60. VMS (the cause of the problem may have had something to do with
  61. interdepartmental politics at DEC--I've had my share of those to deal with,
  62. too [no, don't bother to ask]).
  63.  
  64. -- 
  65. Steve Suttles                Internet:  steve@dbaccess.com      Dr. DCL is IN!
  66. CROSS ACCESS Corporation     UUCP: {uunet,sgiblab}!troi!steve  Yo speako TECO!
  67. 2900 Gordon Ave, Suite 100   fax: (408) 735-0328              Talk data to me!
  68. Santa Clara, CA 95051-0718   vox: (408) 735-7545   HA! It's under 4 lines NOW!
  69.