really bad order of evaluation bug

really bad order of evaluation bug

[John Mackin]

Byron,

I got your mail this morning but haven't had time to reply today, and I have
to get off and sleep soon.  But before I do I thought I had better mail you
this one.  I spent four hours tracking this down today -- sigh.  I thought
I should copy it to the list since it's so very drastic.

The symptom here was that on one particular type of machine -- Sony News,
but the 68000 one, not the MIPS one -- redirection wasn't working right.
If you did

ls thisisntthere >xxxx >[2=1]

then the error message -- which was most definitely getting printed on
fd 2 -- came out _on the terminal_, and xxxx ended up with nothing in it.
This didn't happen on any other machine I had easy access to.  Actually,
having found it, I'm really surprised that it isn't broken in more
places: perhaps it is and people just haven't noticed.  This is an
order of evaluation bug in glom.c, which was introduced between 0.9
and 1.0 -- 1.0 has new code here and it has been broken ever since.
Here is the fix:

*** glom.c-BUG	Wed Jan 29 18:42:34 1992
--- glom.c	Wed Jan 29 18:41:48 1992
***************
*** 516,522 ****
  			}
  			words = words->u[0].p;
  		}
! 		return append(append(glom(words), last), glom(n->u[1].p));
  	case BACKQ:
  		return backq(n->u[0].p,n->u[1].p);
  	case CONCAT:
--- 516,523 ----
  			}
  			words = words->u[0].p;
  		}
! 		first = append(glom(words), last);
! 		return append(first, glom(n->u[1].p));
  	case BACKQ:
  		return backq(n->u[0].p,n->u[1].p);
  	case CONCAT:

I guess that either damn near every compiler out there evaluates
function arguments left-to-right (where _are_ the pcc-based ones
any more? :), or else the people who use right-to-left compilers
don't use `fancy' redirections....

I'll reply to your other mail tomorrow my time.  Say 10-12 hours.

OK,
John.