home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / lang / apl / 1186 < prev    next >
Encoding:
Text File  |  1992-11-17  |  2.9 KB  |  72 lines
  1. Newsgroups: comp.lang.apl
  2. Path: sparky!uunet!utcsri!geac!itcyyz!yrloc!hui
  3. From: hui@yrloc.ipsa.reuter.COM (Roger Hui)
  4. Subject: Re: Potential (Minor) Problems with J6.0
  5. Message-ID: <1992Nov18.055918.24509@yrloc.ipsa.reuter.COM>
  6. Organization: Iverson Software Inc.
  7. References: <1992Nov10.160147.6619@Trirex.COM>
  8. Date: Wed, 18 Nov 92 05:59:18 GMT
  9. Lines: 61
  10.  
  11. Tom Affinito writes:
  12.  
  13. > I'm using a NeXT, system 3.0, which uses the gcc compiler version 1.93.
  14. > This version of gcc had a fatal error in the file vh.c, and since fatal
  15. > errors do not generate line numbers I had to play with commenting out
  16. > sections of the source until I narrowed the problem down to the following
  17. > code fragment in function hiat
  18. >
  19. > d=t&BOOL?*(B*)yv:t&INT?*(I*)yv:*(D*)yv; d*=hct;
  20. >
  21. > The d*=hct end is fine, but the first part was the troublemaker for this
  22. > version of gcc; it appears that gcc has problems with the conditional
  23. > operators when it gets nested a couple of levels.  I did not fully examine
  24. > this bug, but the problem went away when I replaced that first part of the
  25. > line with
  26. >
  27. > if (t&BOOL)
  28. >    d = (*(B*)yv);
  29. > else if (t&INT)
  30. >    d = (*(I*)yv);
  31. > else
  32. >    d = (*(D*)yv);
  33.  
  34. Thanks.  I'd previously run into similar problems with GCC on vh.c,
  35. but had neither time nor patience to persist, and worked around 
  36. the problems by not using the optimizer flag "-O" on this file.  
  37. I suspect the GCC bug has more to do with the "polymorphic pointer" 
  38. handling than with the ?: nesting (which occurs many times in the source).  
  39. I'll incorporate the intent of this change.
  40.  
  41. > The next part IS an ISI bug, and it's in the sample main.c that gets used
  42. > when compiling LinkJ.
  43. >
  44. > The main routines loops, waiting for a Ctrl-D, and contains this line:
  45. > if('\004'==*v)exit(0); else if('\n'==*v)*v=0;
  46. >
  47. > This is faulty because the string v is fetched through gets, which 1) does
  48. > not place '\n' in the string buffer anyway, but replaces it with '\0'
  49. > (unlike fgets), and 2) does not specify what gets read when the EOF
  50. > is generated.
  51. >
  52. > The behavior on the NeXT is that pressing Ctrl-D causes the program to
  53. > loop forever, reevaluating the last input over and over and over again.
  54. > A solution is to replace the while with the following
  55. >  while(1){
  56. >   printf("   "); if (NULL == gets(s)) exit(0);
  57. >   v=s+strlen(s)-1;
  58. >   t=jx(s);
  59. >   if(jerr)printf("jerr: %d\n",jerr); else if(!asgn)jpr(t);
  60. >  }
  61.  
  62. I suppose one can call these bugs, although main.c is a sample and is not
  63. meant to be the final word on how to use LinkJ.  1) is definitely not a bug.
  64. It is redundant at worst.  To do the input properly, one really should use
  65. fgets() instead of gets(), and for fgets() the '\n'==*v is necessary.
  66. (But I am unwilling to devote the effort to use fgets() in what is
  67. only a sample.)  2) is a bug.  Thanks for the proposed solution.
  68.  
  69. ------------------------------------
  70. Roger Hui, Iverson Software Inc., 33 Major Street, Toronto, Ontario  M5S 2K9
  71. Phone: (416) 925 6096;  Fax: (416) 488 7559
  72.