home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.29 / text0078.txt < prev    next >
Encoding:
Text File  |  1992-12-26  |  1.5 KB  |  34 lines
  1. Submitted-by: djb@cbosgd.att.com (David J Bryant)
  2.  
  3. Regarding "POSIX == SVID?", sp@osf.org (Simon Patience) wrote:
  4.   
  5.   > What OSF does with the AES is to make it a superset of standards like
  6.   > POSIX, XPG etc, (assuming that conflicting standards don't prevent it).
  7.   > I would guess that USL does the same with SVID. This means that if you
  8.   > are AES (or SVID) compliant you are therefore also POSIX (or XPG, etc) 
  9.   > compliant automatically.
  10.  
  11. To my knowledge, this is not true for SVID3.  Being SVID3 compliant does not 
  12. necessarily mean you are POSIX & XPG3 compliant.
  13.  
  14. For example, SVID3 specifies two different mechanisms for internationalized 
  15. message handling, one based on catgets(), and one based on gettext().  I know
  16. that catgets() is from XPG3, while gettext() is neither XPG3 or POSIX.
  17. You must take care to select the "right" routines from SVID3 if you wish your
  18. application to be XPG3 compliant as well.  I assume there are other examples
  19. of this situation throughout SVID3.
  20.  
  21. I'd be interested in any comparative analysis of XPG3 (now XPG4), POSIX and
  22. ANSI C that pointed out areas of conflict or incompatibility.  Maximal 
  23. portability is important to my applications, and this kind of information would
  24. certainly help out.
  25.  
  26. David Bryant
  27. AT&T Bell Laboratories       djb@cborion.cb.att.com
  28. Room 1B-256                            djb@cbosgd.att.com
  29. 6200 East Broad Street          PHONE: (614) 860-4516
  30. Columbus, Ohio  43213             FAX: (614) 868-4302
  31.  
  32. Volume-Number: Volume 29, Number 78
  33.  
  34.