Как аппаратное обеспечение может повлиять на инициализацию массива символов C++ ⇐ C++

[Anonymous]

I have a (very) legacy c++ program that uses a character array, and then subsequently concatenates to the variable.

char FileName[FILENAME_SIZE]; strcat(FileName, "/home/"); Despite not being initialized (this is not static or anything, just within a function block), this has worked for a couple years. But someone attempted to run our SW on a different HW platform and the FileName variable then has uninitialized values and therefore the strcat() command appends to the end of the gibberish, and the result is usually some unprintable characters followed by the "/home/", which then fails fopen() because of the prefixed gibberish. Replacing strcat with strcpy resolves the issue.

So I can say with 100% certainty, over hundreds of thousands of runs, the value after the strcat() on our current HW and virtualized systems (KVM) is always correct and pretty much never right on this different HW (I think it was maybe right one time, when the first byte randomly was '\0'). I understand the code isn't correct, and the value should be initialized with memset or just use strncpy or any number of more modern methods. But I'm trying to understand how the HW can impact such an initialization because changing the source may not be an option.

The SW loads on each system are "100%" identical. In that we can take a boot drive from one machine and have it work, move to other machine and the character initialization differs. Both systems have 128 GB RAM, same NVIDIA P5000 card. The motherboard/CPU is the largest difference. The working system is 40 core while the non-working is only 10 core. But reducing the working system to 10 core in the BIOS had no impact.

I went through and disabled all cpu flags (using clearcpuid flags) on the new HW such that the output of

cat /proc/cpuinfo | grep ^flags | tail -1 was identical, except the new system had a cpu flag of 'art' which would not disable despite adding 'clearcpuid=106' to the grub boot parameters.

So all this information to ask the question, what else would control variable initialization? It can't be the compiler or the kernel (unless it is some runtime flags). I can't think of what else to compare and contrast, the goal would be to run on the new HW without having to change/recompile the SW, but rather some OS/BIOS setting as it could drive months of regression testing (as I mentioned, legacy program).

This was replicated in both RHEL8 and RHEL9.

I sadly no longer have the 'new' HW but could possible reach back to the customer to test/compare.

Any thoughts are appreciated.

*Updated to reflect the fact that I discovered this code was recently altered and I was unaware. Originally the code was doing the strncpy to properly initialize the variable, and it was changed to the strcat (with the rational that strcat would null terminate in a single command versus taking two when using strncpy). So while my original statements that his has been working for 20 years were entirely false, it still has worked over countless test runs on the current HW and fails on the new HW, with that being the only known variable.


Источник: https://stackoverflow.com/questions/781 ... ialization