Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!spool.mu.edu!munnari.oz.au!labtam!iand
From: iand@labtam.labtam.oz (Ian Donaldson)
Newsgroups: comp.bugs.sys5
Subject: Re: Csh if statement missing endif bug
Message-ID: <iand.675836768@labtam>
Date: 2 Jun 91 04:26:08 GMT
Article-I.D.: labtam.iand.675836768
References: <1991May31.153937.16414@minnow.sp.unisys.com>
Organization: Labtam Australia Pty. Ltd., Melbourne, Australia
Lines: 33

kjt@minnow.sp.unisys.com (Kevin Thomas) writes:
>I'd be interested to know how widespread is this problem.  If you'd like to
>give the above example a try on your OS and mail me the results, I will
>summarize for the net.

I don't know if this problem is related to the ones I have seen but it
probably is.

The problem is probably due to an incorrect port of csh using a new C compiler
that does automatic register allocation optimization.  Csh depends
on certain variables NOT being promoted to registers for proper functionality.
(ie: longjmp processing depends on it)

In short the quick and dirty way to fix this is to tell the C compiler
not to promote non-register variables to 'register' when compiling csh.

The long and slow way to sort this out is to locate all places
that it matters and fix them.

I found this same problem with an old Encore SVR3 a few years ago
and AT&T SVR4.0 csh.  In both cases the same thing happened.  If there was an 
error in your ".cshrc" or ".login" it caused it to go crazy malloc()ing 
until you ran out of virtual memory.  

For the Encore case, I compiled up my own 4.3-tahoe csh with 
register optimization disabled, and for SVR4.0 I recompiled the csh 
similarly and the problems vanished.  

I also managed to find one piece of code where I could prevent the bug
occuring with register optimization enabled, but I gave up after
a long while looking for the others... its not worth the time to me.

Ian D