Bug: iparmq_ function crash due to incorrect name_len assignment (f2c string, s_copy macro, roots/Armadillo/Win10/MSVC2019)

[ZeroPointField]

Summary

A crash or undefined behavior occurs in the LAPACK auxiliary routine iparmq_ due to name_len being set to 0 before calling s_copy, resulting in invalid string copying and uninitialized memory access.

---

Steps to reproduce / Environment

• High-level library: Armadillo (C++ linear algebra library)
• Function: roots
• Platform: Windows 10 x64
• Compiler: MSVC 2019
• OpenBLAS build: develop branch, built with MSVC2019 (64-bit)

---

Problem details

When using Armadillo's roots function (internally triggers LAPACK/exposed via OpenBLAS), program crashes in iparmq_ (f2c-generated LAPACK code). The bug lies in this code section:

char subnam[6];
integer name_len = 0;
s_copy(subnam, name__, (ftnlen)6, name_len);

Because name_len is set to 0, s_copy does not copy any characters from name__, leaving subnam uninitialized. Subsequent access (e.g., s_cmp, pointer arithmetic) reads undefined memory and causes a crash.

Macro context:

#define f2cmin(a,b) ((a) <= (b) ? (a) : (b))
#define s_copy(A,B,C,D) { int __i,__m; for (__i=0, __m=f2cmin((C),(D)); __i<__m && (B)[__i] != 0; ++__i) (A)[__i] = (B)[__i]; }

• When D==0, no copy occurs; subnam remains uninitialized stack memory.

---

User workaround confirmation / test result

Manually patching to name_len = strlen(name__); eliminates the crash. Results of Armadillo's roots match MATLAB, confirming functional correctness in this environment (likely due to NUL-terminated C string via MSVC/f2c/Armadillo stack). However, this is not portable, as pure Fortran calls may not guarantee NUL-termination or C string conventions.

---

Recommendation / Fix

• Preferred: Change routine signature to accept the hidden Fortran length argument (ftnlen name_len) and pass this to s_copy (the Fortran/C interface standard for f2c-converted code).
• Workaround: If changing interface is not feasible, compute the argument length safely (e.g., use strlen(name__) but only if NUL-terminated is guaranteed; otherwise, implement a Fortran-compatible length computation).
• At minimum: Zero out subnam before access to prevent undefined reads, but this hides the real bug.

---

Impact

Affects any high-level code using OpenBLAS/LAPACK f2c wrappers in environments similar to the above (Win10/MSVC/Armadillo/roots). Likely applies to other platforms/builds using the same pattern.

---

Please review and fix as appropriate, and consider auditing similar f2c-generated string handling sites.

---

中文摘要：
在 Win10 x64 MSVC2019 下，使用Armadillo库调用 roots 时，OpenBLAS-develop（LAPACK/f2c/src/iparmq_）内部 name_len=0 直接传给 s_copy，subnam 未初始化后续代码读取崩溃。用 name_len=strlen(name__) 后功能恢复。建议官方修正形参与长度传递，或实现更通用的字符串长度拷贝处理逻辑。

---

环境测试人/反馈人：@ZeroPointField （如需进一步日志、testcase 可补充）