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
