home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / rexx / 905 < prev    next >
Encoding:
Text File  |  1992-09-08  |  2.6 KB  |  50 lines
  1. Newsgroups: comp.lang.rexx
  2. Path: sparky!uunet!mcsun!sunic!sejnet.sunet.se!eric
  3. From: eric@sejnet.sunet.se (Eric Thomas)
  4. Subject: Re:      Re: Blanks, REXX, and portability...
  5. Message-ID: <1992Sep6.022654.1@sejnet.sunet.se>
  6. Lines: 37
  7. Sender: news@sunic.sunet.se
  8. Reply-To: ERIC@SEARN.SUNET.SE
  9. Organization: SUNET, Stockholm, Sweden
  10. References: <9209051944.AA18020@lns598.TN.CORNELL.EDU>
  11. Date: Sun, 6 Sep 1992 02:26:54 GMT
  12.  
  13. In article <9209051944.AA18020@lns598.TN.CORNELL.EDU>,         cultural elite <dsr@LNS598.TN.CORNELL.EDU> writes:
  14. > I agree, that would be ridiculous.  Not even Unix (with the possible exception
  15. > of a few broken utilities) behaves that way.
  16.  
  17. With the possible exception of, for instance, scanf(), the C formatted read
  18. routine. Ever tried to use scanf() to read a one-word reply from the terminal,
  19. and use a default value if the user just hits RETURN? scanf() insists that all
  20. these carriage returns are just white space which should be happily ignored,
  21. and the user wonders what is going on - the more he hits RETURN, the more
  22. nothing happens. Yes, I know, there are ways out, but the least you can say is
  23. that they are unintuitive...
  24.  
  25. > Mike's question was specifically about word separators, which
  26. > I take to mean the behavior of parse when no explicitly quoted separators are
  27. > given, and the behavior of word() and words() and a few other intrinsics.
  28. > Accepting any whitespace as word separators would have no effect on your
  29. > example, or any other involving explicitly quoted blanks.  Where is the problem
  30. > with that?
  31.  
  32. The problem is that if you want to change the language definition of all these
  33. functions, you have to come up with a solution that is clearly defined and
  34. works for all systems, not just unix. One such solution, which is what I
  35. understood all the previous postings were proposing, is that positional PARSE
  36. et al are to treat any character for which isspace() returns TRUE as white
  37. space.
  38.  
  39. Under VM, isspace() is true for X'05' and X'15'. It is logical for isspace() to
  40. be true for these characters, since they are the EBCDIC equivalents of TAB and
  41. CRLF, respectively; as far as I know, all the C compilers for VM agree on this.
  42. I'm not really eager to find out what happens to my tens of thousands of lines
  43. of code the day X'15' is suddenly treated as a blank. It is used as a
  44. line-separator in functions like DIAG, and it is common programming practice to
  45. use it as a line separator when returning more than one line of (non-binary)
  46. data from a function. I suppose a similar situation exists for \n on unix
  47. systems, but I've never used REXX on unix so I wouldn't know.
  48.  
  49.   Eric
  50.