[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Source Code Bug in Bash-4.3.33 Module variables.c

From: Eric Robertson
Subject: Source Code Bug in Bash-4.3.33 Module variables.c
Date: Sat, 07 Mar 2015 11:59:09 -0500
User-agent: Mozilla/5.0 (X11; U; OpenVMS AlphaServer_ES40; en-US; rv: Gecko/20081029 SeaMonkey/1.1.12


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:


     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:

address@hidden:/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);



reply via email to

[Prev in Thread] Current Thread [Next in Thread]