Re: Bugs on SourceForge

Re: Bugs on SourceForge

[Sven Wischnowsky]

Bart Schaefer wrote:

> We should at least address 219457 and 219459 before 4.0.1, not because I
> submitted them, but because they're shell-crashers.

219457 doesn't crash for me, probably because of 12247.

219459 crashes, yes.  I don't dare to touch the typeset code...

> I suspect 232305 has already been taken care of by the configure system,
> but can somebody who has a Solaris box please check?

Just tried on Solaris 2.6 and there at least it seems to be fixed.  We 
don't have a newer Solaris version here, though.


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: Bugs on SourceForge

[Jason Price]

> } Subject: Re: Bugs on SourceForge
> } I sent this info through, and it seems to have come through the mailing
> } list alright... (procmail logs at least claim so).  Did everyone receive
> } it? 
> I think so, but I'm limited in what I can do about it because I don't have
> access to a Solaris system.
> If you "configure --disable-lfs", does zsh compile?

Yes it does, and it passes make test as well.

Jason

-- 
"Friendship is the bridge between lonely and loved, between a glance and a
gaze. It stretches from the fog into sunshine, hopelessness into faith, 
between despair and joy. It crosses the chasm from hell and to heaven, from 
God to man, and from you to me." --Unknown   Jason Price  jprice@gatech.edu

Re: Bugs on SourceForge

[Jason Price]

>} I'll have to try this out when I get a moment.  But given the headers are
>} screwy for Solaris 8 (see below), I rather suspect I won't be able to
>} reproduce it.  Certainly works OK on 8 with zsh compiled under 6.
> Note that it was Solaris 6 where Jason is having `rlimit64' problems, so
> the fact that you're able to compile on Solaris 6 but he is not may be
> indicative of ... something ...

Probably largefile support if I had to make a guess...  See below.

>}> On to the datasize tests.
>} These worked, right?  Else I'm missing something.
> They worked.  I closed out the bug report on SourceForge.

Quite correct... I wasn't very clear.
 
>>> 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

>> This looks like another header problem, but this time it's more than
>> just configure complaining.  struct rlimit64 should be defined:
>> [...]
>> 5.8 system.  The complaints are presumbably from the lines
 
>>   extern int setrlimit64(int, const struct rlimit64 *);
>>   extern int getrlimit64(int, struct rlimit64 *);

> Your header certainly makes it appear that it shouldn't be possible to
> compile the above two lines without also having rlimit64 defined.  I've
> already sent mail to Jason asking what his resource.h looks like (and
> he's Cc'd on this message).

Line 148 is:

extern int setrlimit(int, const struct rlimit *);

Here is the relevant portion of resource.h on solaris 2.6:

/*************************************************************************/
#if defined(__STDC__)

extern int setrlimit(int, const struct rlimit *);    /* ** line 148 ** */
extern int getrlimit(int, struct rlimit *);

/* transitional large file interfaces */
#if     defined(_LARGEFILE64_SOURCE) && !((_FILE_OFFSET_BITS == 64) && \
            !defined(__PRAGMA_REDEFINE_EXTNAME))
extern int setrlimit64(int, const struct rlimit64 *);
extern int getrlimit64(int, struct rlimit64 *);
#endif  /* _LARGEFILE64_SOURCE... */

extern int getpriority(int, id_t);
extern int setpriority(int, id_t, int);
extern int getrusage(int, struct rusage *);

#else   /* __STDC__ */

extern int getrlimit();
extern int setrlimit();

/* transitional large file interfaces */
#if     defined(_LARGEFILE64_SOURCE) && !((_FILE_OFFSET_BITS == 64) && \
            !defined(__PRAGMA_REDEFINE_EXTNAME))
extern int setrlimit64();
extern int getrlimit64();
#endif  /* _LARGEFILE64_SOURCE... */

extern int getpriority();
extern int setpriority();
extern int getrusage();

#endif  /* __STDC__ */
/*************************************************************************/

And here's what it looks like in Solaris 8:

/*************************************************************************/
#if defined(__STDC__)

extern int setrlimit(int, const struct rlimit *);
extern int getrlimit(int, struct rlimit *);

/* transitional large file interfaces */
#if     defined(_LARGEFILE64_SOURCE) && !((_FILE_OFFSET_BITS == 64) && \
            !defined(__PRAGMA_REDEFINE_EXTNAME))
extern int setrlimit64(int, const struct rlimit64 *);
extern int getrlimit64(int, struct rlimit64 *);
#endif  /* _LARGEFILE64_SOURCE... */

extern int getpriority(int, id_t);
extern int setpriority(int, id_t, int);
extern int getrusage(int, struct rusage *);

#else   /* __STDC__ */

extern int getrlimit();
extern int setrlimit();

/* transitional large file interfaces */
#if     defined(_LARGEFILE64_SOURCE) && !((_FILE_OFFSET_BITS == 64) && \
            !defined(__PRAGMA_REDEFINE_EXTNAME))
extern int setrlimit64();
extern int getrlimit64();
#endif  /* _LARGEFILE64_SOURCE... */

extern  int getpriority();
extern  int setpriority();
extern  int getrusage();

#endif  /* __STDC__ */
/*************************************************************************/

(I can get solaris 7's version too)

If I had to shoot into the dark about what's causing this, it'd be the
migration path Sun took from 32 bit to 64 bit.  2.6 was the first,
partially 64 bit OS sun made (IIRC).  It only did a 64 bit file system,
leaving the rest of the kernel relativly unharmed.  Solaris 7 was fully 64
bit.

If I can help with things, let me know.  

Jason

-- 
"Friendship is the bridge between lonely and loved, between a glance and a
gaze. It stretches from the fog into sunshine, hopelessness into faith, 
between despair and joy. It crosses the chasm from hell and to heaven, from 
God to man, and from you to me." --Unknown   Jason Price  jprice@gatech.edu

Re: Bugs on SourceForge

[Bart Schaefer]

On May 14,  4:23pm, Peter Stephenson wrote:
}
} I'll have to try this out when I get a moment.  But given the headers are
} screwy for Solaris 8 (see below), I rather suspect I won't be able to
} reproduce it.  Certainly works OK on 8 with zsh compiled under 6.

Note that it was Solaris 6 where Jason is having `rlimit64' problems, so
the fact that you're able to compile on Solaris 6 but he is not may be
indicative of ... something ...

} > On to the datasize tests.
} 
} These worked, right?  Else I'm missing something.

They worked.  I closed out the bug report on SourceForge.
 
} > 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
} 
} This looks like another header problem, but this time it's more than just
} configure complaining.  struct rlimit64 should be defined:
[...]
} 5.8 system.  The complaints are presumbably from the lines
} 
}   extern int setrlimit64(int, const struct rlimit64 *);
}   extern int getrlimit64(int, struct rlimit64 *);

Your header certainly makes it appear that it shouldn't be possible to
compile the above two lines without also having rlimit64 defined.  I've
already sent mail to Jason asking what his resource.h looks like (and
he's Cc'd on this message).

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Bugs on SourceForge

[Peter Stephenson]

> I suspect 232305 has already been taken care of by the configure system,
> but can somebody who has a Solaris box please check?

This is that `limit' doesn't handle large datasize limits on Solaris.  I
reconfigured and recompiled on Solaris 2.8 and limits up to 8GB worked
fine, including if inherited from tcsh (although that apparently treats
limits of 4GB and over as unlimited).  So this is presumably fixed.  I
haven't changed the bugs database since I don't know where the fix
appeared.

Now I have to recompile back on 2.6 since it can't find libcurses.so...

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: Bugs on SourceForge

[Peter Stephenson]

> We should at least address 219457 and 219459 before 4.0.1, not because I
> submitted them, but because they're shell-crashers.

This should fix any lurking problems with %m in a prompt crashing the
shell.  We don't assume we can write to the return value of getsparam() any
more, which probably wasn't a good assumption at the best of times.  This
is general enough that I haven't looked further down, but I would assume
that we were getting back a "", which gcc would have put in the text
segment, but behaviour with other compilers would differ.  Hence the
variable experiences.

Index: Src/prompt.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/prompt.c,v
retrieving revision 1.4
diff -u -r1.4 prompt.c
--- Src/prompt.c	2001/01/16 13:44:20	1.4
+++ Src/prompt.c	2001/03/29 11:18:23
@@ -392,10 +392,7 @@
 		    for (ss = hostnam; *ss; ss++)
 			if (*ss == '.' && !--arg)
 			    break;
-		    t0 = *ss;
-		    *ss = '\0';
-		    stradd(hostnam);
-		    *ss = t0;
+		    stradd(*ss ? dupstrpfx(hostnam, ss - hostnam) : hostnam);
 		}
 		unqueue_signals();
 		break;

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: Bugs on SourceForge

[Peter Stephenson]

> We should at least address 219457 and 219459 before 4.0.1, not because I
> submitted them, but because they're shell-crashers.

The simplest way of fixing the problem of typesetting parameters before
they are autoloaded is to forbid it.  I can't see any time it could
conceivably be useful to allow it, since the whole point of autoloaded
parameters is that they get set up when they're loaded, and it's up to
zmodload, not typeset, to turn off autoloading.

Index: Src/builtin.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/builtin.c,v
retrieving revision 1.42
diff -u -r1.42 builtin.c
--- Src/builtin.c	2001/02/14 23:36:23	1.42
+++ Src/builtin.c	2001/03/29 10:16:11
@@ -1628,10 +1628,16 @@
 	if ((tc = chflags && chflags != (PM_EFLOAT|PM_FFLOAT)))
 	    usepm = 0;
     }
-    if (tc && (pm->flags & PM_SPECIAL)) {
-	zerrnam(cname, "%s: can't change type of a special parameter",
-		pname, 0);
-	return NULL;
+    if (tc){
+	if (pm->flags & PM_SPECIAL) {
+	    zerrnam(cname, "%s: can't change type of a special parameter",
+		    pname, 0);
+	    return NULL;
+	} else if (pm->flags & PM_AUTOLOAD) {
+	    zerrnam(cname, "%s: can't change type of autoloaded parameter",
+		    pname, 0);
+	    return NULL;
+	}
     }
 
     /*

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Bugs on SourceForge

[Bart Schaefer]

We should at least address 219457 and 219459 before 4.0.1, not because I
submitted them, but because they're shell-crashers.

I suspect 232305 has already been taken care of by the configure system,
but can somebody who has a Solaris box please check?

The others can all be put off, unless Adam wants to go crazy with 204884.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net