Source Code Bug in Bash-4.3.33 Module variables.c

[Eric Robertson]

Chet,

The Open Source on OpenVMS group has been building Bash for OpenVMS 
since Bash-4.2.45. Because OpenVMS is not a GNU based operating system, 
Bash for OpenVMS has to be initially built using a special script 
procedure written in the OpenVMS native Digital Command Language (DCL) 
in order to "bootstrap" Bash into existence so that it can then be used 
to execute the GNU based build scripts for other GNU software. One side 
effect of this is that the DCL procedure that builds Bash is 
specifically coded to abort when any compilation warning is emitted from 
a compilation of any Bash source module. Any such warning has to be 
analyzed by  us and , if appropriate, suppressed to permit the build to 
proceed.

When building the bash-4.3.33 release we came upon a source code bug 
which immediately aborted the build for this release of bash. Actually 
this source code bug was introduced with  the bash-4.3.31 release. But, 
since  we did not happen to attempt to build that release  we did not 
report it at the time of that release.

In any case, the abort message from the OpenVMS C compiler was as follows:

CC/name=(as_i,shor)/repo=lcl_root:[bash.cxx_repository]/debu/list/mach/show=(EXPA,INC)/prefix=(all,exce=(strtoimax,strtoumax))/neste
d=none/define=(_USE_STD_STAT=1,_POSIX_EXIT=1,HAVE_CONFIG_H=1)/OBJ=VARIABLES.OBJ 
LCL_ROOT:VARIABLES.C

     ind = array_expand_index (name, subp, sublen);
..................................................^
%CC-W-PTRMISMATCH, In this statement, the referenced type of the pointer 
value "name" is "const char", which is not compatible with
"struct variable".
at line number 2576 in file LCL_ROOT:[bash]VARIABLES.C;1
%MMK-F-ERRUPD, error status %X10B91260 occurred when updating target 
VARIABLES.OBJ

Such warnings about type disagreements are always suspicious when 
non-void (or non-void *) types are involved and, as it turns out, this 
source code statement is indeed completely illogical as the called 
function (array_expand_index in this particular case) has no logical 
provision within its implementation for dealing with a const char * as 
its first argument. From the context of the preceding source code, it 
was apparent that the name of the first argument to this function should 
be changed from "name" to "entry" in order for the statement to be both 
logically correct and type compatible with the function being called. Of 
course, it is completely possible for the compiler to generate the 
machine instructions to carry out the call as originally written. But, 
the execution of those generated instructions would have at the very 
least produce undefined behavior and at worst a core dump.

The diff for the correction against the variables.c module for 
bash-4.3.33 follows:

ROBERTSON@srvr1:/src_root/bash > diff -uN variables.c.orig variables.c
--- variables.c.orig    Sat Mar  7 10:19:39 2015
+++ variables.c Sat Mar  7 09:34:04 2015
@@ -2573,7 +2573,7 @@
      entry = make_new_array_variable (newname);       /* indexed array 
by default */
      if (entry == 0)
       return entry;
-      ind = array_expand_index (name, subp, sublen);
+      ind = array_expand_index (entry, subp, sublen);
      bind_array_element (entry, ind, value, aflags);
    }
#endif

Regards,

Eric