PATCH: pws-21: minor fixes

PATCH: pws-21: minor fixes

[Peter Stephenson]

I looked again at Andrej's logfile from compiling with --enable-lfs, and it
was even less interesting than the first time.  I've only made a couple of
changes to the use of long integers, where it's just possible a
user-supplied string might be too long.  Otherwise, there are still places
where there are conversions for things like the lengths of strings, sizes
of windows, return values, pids, line numbers, times (time_t is used fairly
consistently for these and is usually 32-bit) and so on, where there
doesn't seem any point in using longer integers.

In fact, most of the changes are other little things that turned up, like
comparing different types, or variables set but never used.  I also found
out there wasn't an entry for `subscript' in the manual index, and I can
never find where they're described.

--- Doc/Zsh/params.yo.ab	Thu Jun 10 10:37:39 1999
+++ Doc/Zsh/params.yo	Thu Jun 10 10:38:03 1999
@@ -59,6 +59,7 @@
 expansion as if it were surrounded by `tt($LPAR()LPAR())...tt(RPAR()RPAR())'.
 The elements are numbered beginning with 1 unless the
 tt(KSH_ARRAYS) option is set when they are numbered from zero.
+cindex(subscripts)
 pindex(KSH_ARRAYS, use of)
 
 The same subscripting syntax is used for associative arrays,
--- Src/Modules/zftp.c.ab	Mon May 17 16:41:32 1999
+++ Src/Modules/zftp.c	Thu Jun 10 10:53:59 1999
@@ -230,7 +230,7 @@
 static int lastcode;
 
 /* flag for remote system is UNIX --- useful to know as things are simpler */
-static int zfis_unix, zfpassive_conn;
+static int zfpassive_conn;
 
 /* remote system has size, mdtm commands */
 enum {
@@ -1786,7 +1786,6 @@
 	return 1;
     }
 
-    zfis_unix = 0;
     zfhas_size = zfhas_mdtm = ZFCP_UNKN;
     zdfd = -1;
     /* initial status: open, ASCII data, stream mode 'n' stuff */
@@ -2039,14 +2038,12 @@
 		/*
 		 * Use binary for transfers.  This simple test saves much
 		 * hassle for all concerned, particularly me.
+		 *
+		 * We could set this based just on the UNIX part,
+		 * but I don't really know the consequences of that.
 		 */
 		zfstatus |= ZFST_IMAG;
-		zfis_unix = 1;
 	    }
-	    /*
-	     * we could set zfis_unix based just on the UNIX part,
-	     * but I don't really know the consequences of that.
-	     */
 	    zfsetparam("ZFTP_SYSTEM", systype, ZFPM_READONLY);
 	}
 	zfstatus |= ZFST_SYST;
--- Src/hashtable.c.ab	Wed Jun  9 16:18:36 1999
+++ Src/hashtable.c	Thu Jun 10 10:29:34 1999
@@ -1327,7 +1327,7 @@
 {
     HashNode oldnode = addhashnode2(ht, nam, nodeptr);
     Histent he = (Histent)nodeptr;
-    if (oldnode && oldnode != nodeptr) {
+    if (oldnode && oldnode != (HashNode)nodeptr) {
 	if (he->flags & HIST_MAKEUNIQUE
 	 || (he->flags & HIST_FOREIGN && (Histent)oldnode == he->up)) {
 	    he->flags |= HIST_DUP;
--- Src/loop.c.ab	Wed Jun  9 16:18:39 1999
+++ Src/loop.c	Thu Jun 10 10:32:04 1999
@@ -51,7 +51,7 @@
 {
     Forcmd node;
     char *str;
-    int val = 0;
+    zlong val = 0;
     LinkList args;
 
     node = cmd->u.forcmd;
--- Src/math.c.ab	Wed Jun  9 16:18:10 1999
+++ Src/math.c	Thu Jun 10 10:34:15 1999
@@ -826,7 +826,8 @@
 static void
 mathparse(int pc)
 {
-    int q, otok, onoeval;
+    zlong q;
+    int otok, onoeval;
 
     if (errflag)
 	return;
--- Src/params.c.ab	Thu Jun 10 10:45:15 1999
+++ Src/params.c	Thu Jun 10 10:43:24 1999
@@ -722,16 +722,13 @@
 #endif
 }
 
-static char **garr;
-
 /**/
 static zlong
 getarg(char **str, int *inv, Value v, int a2, zlong *w)
 {
-    int num = 1, word = 0, rev = 0, ind = 0, down = 0, l, i, ishash;
-    int beg = 0, hasbeg = 0;
+    int hasbeg = 0, word = 0, rev = 0, ind = 0, down = 0, l, i, ishash;
     char *s = *str, *sep = NULL, *t, sav, *d, **ta, **p, *tt;
-    zlong r = 0;
+    zlong num = 1, beg = 0, r = 0;
     Comp c;
 
     ishash = (v->pm && PM_TYPE(v->pm->flags) == PM_HASHED);
@@ -1146,7 +1143,6 @@
     int ppar = 0;
 
     s = t = *pptr;
-    garr = NULL;
 
     if (idigit(*s)) {
 	if (bracks >= 0)
--- Src/subst.c.ab	Fri Jun  4 13:53:27 1999
+++ Src/subst.c	Thu Jun 10 10:45:50 1999
@@ -53,9 +53,9 @@
 
     MUSTUSEHEAP("prefork");
     for (node = firstnode(list); node; incnode(node)) {
-	char *str, *str3;
+	char *str;
 
-	str = str3 = (char *)getdata(node);
+	str = (char *)getdata(node);
 	if ((*str == Inang || *str == Outang || *str == Equals) &&
 	    str[1] == Inpar) {
 	    if (*str == Inang || *str == Outang)
--- Src/utils.c.ab	Wed Jun  9 16:20:22 1999
+++ Src/utils.c	Thu Jun 10 10:47:37 1999
@@ -1733,13 +1733,12 @@
 sepjoin(char **s, char *sep)
 {
     char *r, *p, **t;
-    int l, sl, elide = 0;
+    int l, sl;
     char sepbuf[3];
 
     if (!*s)
 	return "";
     if (!sep) {
-	elide = 1;
 	sep = sepbuf;
 	sepbuf[0] = *ifs;
 	sepbuf[1] = *ifs == Meta ? ifs[1] ^ 32 : '\0';

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

RE: PATCH: pws-21: minor fixes

[Andrej Borsenkow]

>
> I looked again at Andrej's logfile from compiling with
> --enable-lfs, and it
> was even less interesting than the first time.  I've only made a couple of
> changes to the use of long integers, where it's just possible a
> user-supplied string might be too long.  Otherwise, there are still places
> where there are conversions for things like the lengths of strings, sizes
> of windows, return values, pids, line numbers, times (time_t is
> used fairly
> consistently for these and is usually 32-bit) and so on, where there
> doesn't seem any point in using longer integers.
>

One thing, that still bothers me, is mapfile. In case of LFS (64-on-32)
address space is most probably limited to 32 bits, that means, it is
impossible to map large file. I do not supose, anybody would do this on
purpose, but what happens if somebody makes mistake? Currently file size is
silently passed to mmap ... that truncates it and (in worst case) maps some
part of file. And even worse, can file be truncated as a result?

Or am I just paranoid?

/andrej

Re: PATCH: pws-21: minor fixes

[Peter Stephenson]

"Andrej Borsenkow" wrote:
> One thing, that still bothers me, is mapfile. In case of LFS (64-on-32)
> address space is most probably limited to 32 bits, that means, it is
> impossible to map large file. I do not supose, anybody would do this on
> purpose, but what happens if somebody makes mistake? Currently file size is
> silently passed to mmap ... that truncates it and (in worst case) maps some
> part of file. And even worse, can file be truncated as a result?

The length parameter to mmap() is size_t, which is quite often shorter than
off_t on this sort of system, so certainly it's possible to have problems.
But this must surely be completely generic to just about any program that
has to have a complete file in memory, which presumably includes any simple
text editor --- it's certainly far beyond the scope of a zsh module to
solve.  However, I can add some more dark hints to the already longish
`Limitations' section of the manual.

The truncation problem can only happen when you read and then write the
file (e.g. vared); simply reading the file with $mapfile[..] can't hurt it
since that only uses PROT_READ so has kernel-level protection against
writing.  Any assignment to mapfile[...] is fraught with danger anyway (for
example, it doesn't respect NOCLOBBER, though I could presumably make it);
I would think problems of truncation of 2GB files are the least of anyone's
worries.

--- Doc/Zsh/mod_mapfile.yo.lim	Sat May 22 16:28:41 1999
+++ Doc/Zsh/mod_mapfile.yo	Thu Jun 10 16:08:00 1999
@@ -35,7 +35,9 @@
 gain in efficiency over use of other mechanisms.  Note in particular that
 the whole contents of the file will always reside physically in memory when
 accessed (possibly multiple times, due to standard parameter subsitution
-operations).
+operations).  In particular, this means handling of sufficiently long files
+(greater than the machine's swap space, or than the range of the pointer
+type) will be incorrect.
 
 No errors are printed or flagged for non-existent, unreadable, or
 unwriteable files, as the parameter mechanism is too low in the shell

-- 
Peter Stephenson <pws@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy