On POSIX Compliance, RTL8, and Why You Should Migrate to V8.4-2L3
As standard support for OpenVMS V8.4-2L1 for Integrity ends in December 2024, we strongly recommend that customers upgrade to V8.4-2L3. While extended engineering support for V8.4-2L1 remains available, the transition to V8.4-2L3 is advised to ensure increased compliance with the latest standards and continued optimal performance. However, some customers have encountered issues with the RTL8 kit on V8.4-2L3, which have hindered their ability to upgrade. This article aims to outline these issues and provide our recommended solutions.
Mark Stiles, the L3 engineer working with RTL patch kits, explains, "There is a modification in the RTL V8 kit which introduced a problem for legacy code. It is responsible for the DECwindows startup problem below and may be (and likely is) the cause of the access violations mentioned below. In brief, a change to tighten up POSIX-compliant routines in memory allocation use had unintended side effects when both POSIX and non-POSIX methods of application virtual memory access were used simultaneously, and may have bled into even just non-POSIX aware code. We are fairly certain we have the fix for this and intend to release it along with other changes in an RTL V9 kit (we know that it fixes the DECwindows startup problem). We have recommended customers who experience issues with the RTL V8 kit remain on the prior RTL V6 kit until the V9 kit is available.
There are several problems which have been found in the PTHREAD$RTL image, most of which was found during x86 testing which exposed some latent issues which seldom appeared in previous architectures. Most of these were timing issues with synchronization. There is a PTHREAD V1.0 kit for V8.4-2L3, I recommend the customer see if that solves the issue they are having.
To summarize, if your issue pertains to DECwindows or involves access violations (ACCVIOs), please wait for the RTL9 kit, which will be released later this year. For issues related to pthreads, try the PTHREAD V1.0 kit.
There is also a third category of C RTL problems reported by customers, often caused by application code relying on uninitialized memory or variables. These issues typically result in access violations (ACCVIOs) and will not be resolved by the RTL9 or PTHREAD kits. Resolving these issues requires changes to the customer’s code, but VSI encourages the customers to make the changes and upgrade to V8.4-2L3.
To illustrate the problem of uninitialized memory, consider the following code example:
#include <stdio.h>
void printArray() {
int array[5]; // uninitialized array
for (int i = 0; i < 5; i++) {
printf("%d ", array[i]); // accessing uninitialized memory
}
printf("\n");
}
int main() {
printArray();
return 0;
}
In this example, the array is an uninitialized array of integers. The compiler allocates memory space for the array but does not initialize the data, leading to unpredictable results each time the code is executed. To initialize the array correctly, all members of the array need to be explicitly assigned some data (such as zeros).
int array[5] = {0}; // initialized array
For zero-initialized memory, it is recommended to use calloc over malloc, and to set pointers to NULL and check them before dereferencing. John Reagan, team lead of the Compiler team at VSI, notes, "while the C standard doesn't define an initial value, many C compilers (including ours) provide extensions to initialize local variables that have no source code initializer. CC/CHECK=UNINITIALIZED_VARIABLES initializes all automatic variables to the value 0x7ff580057ff58005."
Uninitialized memory is dangerous for several reasons:
Reproducibility: bugs are hard to reproduce because behavior can be inconsistent.
Security: uninitialized memory might contain previously allocated data from other parts of the program or other programs which may be sensitive or allow others to gain access to sensitive data.
Portability: code might work on one machine or OS version but fail on another due to differences in memory allocation.
More on the last point from John Reagan: "We have seen many instances of what I'll call "integer size overwrite". Since C provides both 32-bit integers and 64-bit integers, we've seen many programs write into a 32-bit integer with a 64-bit write by mistake. On Alpha and Itanium, our legacy GEM code generator would usually place 32-bit integer locals into their own provide 64-bit container. That really improved performance on early Alphas. It was less important on later generation Alpha and Itanium, but it will make a difference. That optimization is applied all the time even when specifying /NOOPT. So on Alpha and Itanium, that 64-bit write would update the 32-bit variable and write extra bits into that padding area. Unless you had specific tests or specific data patterns, you might never notice that. However on x86, such an optimization has zero benefit and LLVM does not provide it. All your 32-bit local variables are now adjacent to each other. A 64-bit write to one of those variables will now incorrectly overwrite the adjacent variable. That causes programs to fail in all sorts of ways. We have fallen victim to this in our own OS and LP code (I'll guess 6-8 times across the whole code base). It as hard for us to track down in the beginning but now that the debugger is available with its SET WATCH feature, it is a little easier to detect."
C RTL V8 includes improvements and bug fixes to enhance POSIX compliance, particularly in memory allocation. In scenarios where RTL V6 tolerated unpredictable behavior, RTL8 may produce an error, halting the application thus preventing more serious issues. As we ourselves deal with legacy code at VSI, we understand the challenges involved and we still consistently opt to address these issues properly, even if it requires code changes.
Adhering to standards demands additional effort, but it mitigates risks and simplifies long-term maintenance. We are here to assist you: our Application Services team is available to help modernize your code for compatibility with the new C RTL. Please contact your VSI Sales representative to schedule a call.
Chief Executive Officer
