Sorry it's taken soooo long to get back to you on this.

> The bug report is:
> 
>     While native csh on solaris 5.7 ( IMHO even 5.5 ) allows 
>     limit datasize to be upto 4 GB, zsh keeps is below 2 GB. If 
>     i set datasize more in csh, and enter zsh, it reduces datasize 
>     to be 97MB !!! 
> 
> So the thing to do would be to build 4.0.1-pre-2 on Solaris 2.7 (and 2.5
> if possible), start csh, set the limit to something large, then run zsh
> from within csh and check the output of the `limit' command.  Then run
> csh again from within zsh, and see what csh thinks the limits are.
> 
> I suspect that the reporting party's zsh was misconfigured so that it
> didn't use 64 bit longs; the question is whether this was pilot error
> (--disable-lfs, maybe?  Or failure to remove an old config.cache?) or
> whether the configure tests for integer size actually got it wrong.

CVS as of May 10, 10:00am ish (after the one line term.h fix for solaris).

configure's and makes fine on solaris 7 and 8.  make test fails (slightly)
on solaris 8 with:

./A04redirect.ztst: starting.
*** /tmp/zsh.ztst.out.12435     Thu May 10 12:59:21 2001
--- /tmp/zsh.ztst.tout.12435    Thu May 10 12:59:21 2001
***************
*** 1,3 ****
  out1 out2
! out1: All files
! out2: All files
--- 1,3 ----
  out1 out2
! out1: 
! out2: 
Test ./A04redirect.ztst failed: output differs from expected as shown above 
for:
  print *
  print "out1: $(<out1)\nout2: $(<out2)"
Was testing: read multio with globbing
./A04redirect.ztst: test failed.

Make test succedes on solaris 7.

------------------------------------------------------------------------------

On to the datasize tests.

Solaris 8

is3% echo $SHELL
/bin/csh
is3% limit datasize 8388608
is3% limit
cputime         unlimited
filesize        unlimited
datasize        8388608 kbytes
stacksize       8192 kbytes
coredumpsize    0 kbytes
descriptors     1024 
memorysize      unlimited
is3% /usr/local/bin/zsh
is3% limit
cputime         unlimited
filesize        unlimited
datasize        8192MB
stacksize       8MB
coredumpsize    0kB
descriptors     1024
vmemorysize     unlimited
is3% /bin/csh
is3% limit
cputime         unlimited
filesize        unlimited
datasize        8388608 kbytes
stacksize       8192 kbytes
coredumpsize    0 kbytes
descriptors     1024 
memorysize      unlimited

Solaris 7:

agasc37u% echo $SHELL
/bin/csh
agasc37u% limit
cputime         unlimited
filesize        unlimited
datasize        unlimited
stacksize       8192 kbytes
coredumpsize    0 kbytes
descriptors     1024 
memorysize      unlimited
agasc37u% limit datasize 8388608
agasc37u% limit
cputime         unlimited
filesize        unlimited
datasize        8388608 kbytes
stacksize       8192 kbytes
coredumpsize    0 kbytes
descriptors     1024 
memorysize      unlimited
agasc37u% /usr/local/bin/zsh
agasc37u% limit
cputime         unlimited
filesize        unlimited
datasize        8192MB
stacksize       8MB
coredumpsize    0kB
descriptors     1024
vmemorysize     unlimited
agasc37u% /bin/csh
agasc37u% limit
cputime         unlimited
filesize        unlimited
datasize        8388608 kbytes
stacksize       8192 kbytes
coredumpsize    0 kbytes
descriptors     1024 
memorysize      unlimited

------------------------------------------------------------------------------

On to solaris 6 issues:

I can't get solaris 6 to compile.  The errors I get are attached.

The piece of configure that seems broken is (slightly cleaned up for
readability):

configure:2652: gcc -c  -Wall -Wno-implicit -Wmissing-prototypes -O2
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 conftest.c 1>&5
In file included from /usr/include/sys/wait.h:24, from configure:2638:
/usr/include/sys/resource.h:148: warning: `struct rlimit64' declared inside 
					  parameter list
/usr/include/sys/resource.h:148: warning: its scope is only this definition 
					  or declaration,
/usr/include/sys/resource.h:148: warning: which is probably not what you
					  want.
/usr/include/sys/resource.h:149: warning: `struct rlimit64' declared inside 
					  parameter list


If I can help, let me know.  (And I'll be a bit more prompt... :-) )

Jason