home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / lang / c / 18698 < prev    next >
Encoding:
Internet Message Format  |  1992-12-21  |  2.8 KB
  1. Path: sparky!uunet!usc!sdd.hp.com!elroy.jpl.nasa.gov!nntp-server.caltech.edu!eql.caltech.edu!rankin
  2. From: rankin@eql.caltech.edu (Pat Rankin)
  3. Newsgroups: comp.lang.c
  4. Subject: Re: Questions about token merging and trigraphs
  5. Date: 19 Dec 1992 19:53 PST
  6. Organization: California Institute of Technology
  7. Lines: 36
  8. Distribution: world
  9. Message-ID: <19DEC199219532084@eql.caltech.edu>
  10. References: <1TA04FH@cdis-1.compu.com> <XZo2VB1w165w@quest.UUCP>
  11. NNTP-Posting-Host: eql10.caltech.edu
  12. Summary: time to worry about digraphs, not trigraphs
  13. Keywords: trigraph digraph
  14. News-Software: VAX/VMS VNEWS 1.41    
  15.  
  16.      There's not much point arguing about trigraphs now, so long after
  17. the fact.  They cannot be removed until 1999 at the earliest.  However
  18. there is apparently a similar issue which is currently relevant:  the ISO
  19. committee's consideration of adding _digraphs_ (not to replace trigraphs,
  20. but in addition to them).  My only information is hearsay and comes from
  21. assorted postings in this group and/or comp.std.c.
  22.  
  23. In article <XZo2VB1w165w@quest.UUCP>, srhqla!quest!kdq writes...
  24. [ lots of text deleted; this is reportedly a direct quote from the
  25.   ANSI rationale document, which is not part of the actual standard: ]
  26. > "...The obvious idea of defining two-character escape sequences fails
  27. > because C uses all the characters which _are_ in the ISO 646 repetoire:
  28. > no single escape character is available.  The best that can be done is
  29. > to use a _trigraph_ - an escape digraph followed by a distinguishing
  30. > character."
  31.  
  32.      Apparently [a majority of?] the current members of the ANSI committee
  33. don't agree with that any more, if the report that they've decided to stop
  34. actively opposing digraphs is accurate.  If the proposed set of digraphs
  35. affects string literals--I'm not sure, since I don't have all the phases
  36. of compilation memorized, nor a list handy--then at least one of them is
  37. certain to cause problems under VMS.  Angle brackets ("<",">") are valid
  38. alternate delimiters for directory names--inherited from TOPS-10 or TOPS-20,
  39. precisely because the normal square bracket ("[","]") delimiters are not
  40. available on some non-ASCII terminals and printers--and *printf format
  41. strings which reference "<%" (proposed digraph for "{") do exist.  Consider
  42.         sprintf(file_specification, "%s:<%s>%s.%s;%d",
  43.                 device, directory, basename, filetype, version_number);
  44. or the analogous *scanf call for picking a fully-qualified name apart.
  45. I imagine some Unix programs which construct command strings for system()
  46. have similar occurances of "<%s" for redirecting the standard input stream.
  47. This would not be a relatively harmless affect on message text, but a major
  48. breakage for some small but non-zero pecentage of code.  Of course if
  49. digraphs don't apply to string literal processing then this is a moot point...
  50.  
  51.         Pat Rankin, rankin@eql.caltech.edu
  52.