PR/52302 CVS commit: src/bin/sh

["Robert Elz" <kre%netbsd.org@localhost>]

The following reply was made to PR bin/52302; it has been noted by GNATS.

From: "Robert Elz" <kre%netbsd.org@localhost>
To: gnats-bugs%gnats.NetBSD.org@localhost
Cc: 
Subject: PR/52302 CVS commit: src/bin/sh
Date: Sat, 17 Jun 2017 07:22:12 +0000

 Module Name:	src
 Committed By:	kre
 Date:		Sat Jun 17 07:22:12 UTC 2017
 
 Modified Files:
 	src/bin/sh: exec.c expand.c memalloc.c memalloc.h parser.c
 
 Log Message:
 Many internal memory management type fixes.
 
 PR bin/52302   (core dump with interactive shell, here doc and error
 on same line) is fixed.   (An old bug.)
 
 echo "$( echo x; for a in $( seq 1000 ); do printf '%s\n'; done; echo y )"
 consistently prints 1002 lines (x, 1000 empty ones, then y) as it should
 (And you don't want to know what it did before, or why.) (Another old one.)
 
 (Recently added) Problems with ~ expansion fixed (mem management related).
 
 Proper fix for the cwrappers configure problem (which includes the quick
 fix that was done earlier, but extends upon that to be correct). (This was
 another newly added problem.)
 
 And the really devious (and rare) old bug - if STACKSTRNUL() needs to
 allocate a new buffer in which to store the \0, calculate the size of
 the string space remaining correctly, unlike when SPUTC() grows the
 buffer, there is no actual data being stored in the STACKSTRNUL()
 case - the string space remaining was calculated as one byte too few.
 That would be harmless, unless the next buffer also filled, in which
 case it was assumed that it was really full, not one byte less, meaning
 one junk char (a nul, or anything) was being copied into the next (even
 bigger buffer) corrupting the data.
 
 Consistent use of stalloc() to allocate a new block of (stack) memory,
 and grabstackstr() to claim a block of (stack) memory that had already
 been occupied but not claimed as in use.  Since grabstackstr is implemented
 as just a call to stalloc() this is a no-op change in practice, but makes
 it much easier to comprehend what is really happening.  Previous code
 sometimes used stalloc() when the use case was really for grabstackstr().
 Change grabstackstr() to actually use the arg passed to it, instead of
 (not much better than) guessing how much space to claim,
 
 More care when using unstalloc()/ungrabstackstr() to return space, and in
 particular when the stack must be returned to its previous state, rather than
 just returning no-longer needed space, neither of those work.  They also don't
 work properly if there have been (really, even might have been) any stack mem
 allocations since the last stalloc()/grabstackstr().   (If we know there
 cannot have been then the alloc/release sequence is kind of pointless.)
 To work correctly in general we must use setstackmark()/popstackmark() so
 do that when needed.  Have those also save/restore the top of stack string
 space remaining.
 
 	[Aside: for those reading this, the "stack" mentioned is not
 	in any way related to the thing used for maintaining the C
 	function call state, ie: the "stack segment" of the program,
 	but the shell's internal memory management strategy.]
 
 More comments to better explain what is happening in some cases.
 Also cleaned up some hopelessly broken DEBUG mode data that were
 recently added (no effect on anyone but the poor semi-human attempting
 to make sense of it...).
 
 User visible changes:
 
 Proper counting of line numbers when a here document is delimited
 by a multi-line end-delimiter, as in
 
 	cat << 'REALLY
 	END'
 	here doc line 1
 	here doc line 2
 	REALLY
 	END
 
 (which is an obscure case, but nothing says should not work.)  The \n
 in the end-delimiter of the here doc (the last one) was not incrementing
 the line number, which from that point on in the script would be 1 too
 low (or more, for end-delimiters with more than one \n in them.)
 
 With tilde expansion:
 	unset HOME; echo ~
 changed to return getpwuid(getuid())->pw_home instead of failing (returning ~)
 
 POSIX says this is unspecified, which makes it difficult for a script to
 compensate for being run without HOME set (as in env -i sh script), so
 while not able to be used portably, this seems like a useful extension
 (and is implemented the same way by some other shells).
 
 Further, with
 	HOME=; printf %s ~
 we now write nothing (which is required by POSIX - which requires ~ to
 expand to the value of $HOME if it is set) previously if $HOME (in this
 case) or a user's directory in the passwd file (for ~user) were a null
 STRING, We failed the ~ expansion and left behind '~' or '~user'.
 
 
 To generate a diff of this commit:
 cvs rdiff -u -r1.49 -r1.50 src/bin/sh/exec.c
 cvs rdiff -u -r1.115 -r1.116 src/bin/sh/expand.c
 cvs rdiff -u -r1.29 -r1.30 src/bin/sh/memalloc.c
 cvs rdiff -u -r1.16 -r1.17 src/bin/sh/memalloc.h
 cvs rdiff -u -r1.137 -r1.138 src/bin/sh/parser.c
 
 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.