Newsgroups: comp.lang.apl
Path: watmath!watserv2.uwaterloo.ca!torn!utcsri!geac!itcyyz!yrloc!hui
From: hui@yrloc.ipsa.reuter.COM (Roger Hui)
Subject: Re: Potential (Minor) Problems with J6.0
Message-ID: <1992Nov18.055918.24509@yrloc.ipsa.reuter.COM>
Organization: Iverson Software Inc.
References: <1992Nov10.160147.6619@Trirex.COM>
Date: Wed, 18 Nov 92 05:59:18 GMT

Tom Affinito writes:
 
> I'm using a NeXT, system 3.0, which uses the gcc compiler version 1.93.
> This version of gcc had a fatal error in the file vh.c, and since fatal
> errors do not generate line numbers I had to play with commenting out
> sections of the source until I narrowed the problem down to the following
> code fragment in function hiat
>
> d=t&BOOL?*(B*)yv:t&INT?*(I*)yv:*(D*)yv; d*=hct;
>
> The d*=hct end is fine, but the first part was the troublemaker for this
> version of gcc; it appears that gcc has problems with the conditional
> operators when it gets nested a couple of levels.  I did not fully examine
> this bug, but the problem went away when I replaced that first part of the
> line with
>
> if (t&BOOL)
>    d = (*(B*)yv);
> else if (t&INT)
>    d = (*(I*)yv);
> else
>    d = (*(D*)yv);
 
Thanks.  I'd previously run into similar problems with GCC on vh.c,
but had neither time nor patience to persist, and worked around 
the problems by not using the optimizer flag "-O" on this file.  
I suspect the GCC bug has more to do with the "polymorphic pointer" 
handling than with the ?: nesting (which occurs many times in the source).  
I'll incorporate the intent of this change.

> The next part IS an ISI bug, and it's in the sample main.c that gets used
> when compiling LinkJ.
>
> The main routines loops, waiting for a Ctrl-D, and contains this line:
> if('\004'==*v)exit(0); else if('\n'==*v)*v=0;
>
> This is faulty because the string v is fetched through gets, which 1) does
> not place '\n' in the string buffer anyway, but replaces it with '\0'
> (unlike fgets), and 2) does not specify what gets read when the EOF
> is generated.
>
> The behavior on the NeXT is that pressing Ctrl-D causes the program to
> loop forever, reevaluating the last input over and over and over again.
> A solution is to replace the while with the following
>  while(1){
>   printf("   "); if (NULL == gets(s)) exit(0);
>   v=s+strlen(s)-1;
>   t=jx(s);
>   if(jerr)printf("jerr: %d\n",jerr); else if(!asgn)jpr(t);
>  }
 
I suppose one can call these bugs, although main.c is a sample and is not
meant to be the final word on how to use LinkJ.  1) is definitely not a bug.
It is redundant at worst.  To do the input properly, one really should use
fgets() instead of gets(), and for fgets() the '\n'==*v is necessary.
(But I am unwilling to devote the effort to use fgets() in what is
only a sample.)  2) is a bug.  Thanks for the proposed solution.

------------------------------------
Roger Hui, Iverson Software Inc., 33 Major Street, Toronto, Ontario  M5S 2K9
Phone: (416) 925 6096;  Fax: (416) 488 7559
