LAPACK Archives

[Lapack] bugs in ilaenv.c

Hi Steven, thanks for the information. Maybe use in that case. There is 
another reason to use 3.2.1. All Householder reflectors are done in 3.2.1 using 
LARFP() and we found a (subtle numerical) bug in LARFP() and this was fixed in 
subsequent version of LAPACK but this was not reported in CLAPACK (since we 
never updated CLAPACK since 3.2.1). I think you might want to use 
Thanks for pointing the bug in ILAENV in CLAPACK. Julien.

On Apr 17, 2013, at 3:14 PM, Steven Mocking <smocking@Domain.Removed> wrote:

Dear CLAPACK maintainers,

There are various bugs in ilaenv.c that seem to have been introduced in 
3.2.1. They are not present in

Line 42:   char subnam[1];
Line 245: s_copy(c2, subnam + 1, (ftnlen)1, (ftnlen)2);
Line 246: s_copy(c2, subnam + 3, (ftnlen)1, (ftnlen)3);

Because string subnam is only defined with length of one character, 
subnam + 1 and subnam + 3 refer to unallocated memory. There is more 
confusion in the code about the length of subnam:

Line 188: s_copy(subnam, name__, (ftnlen)1, name_len);
Line 197:
      for (i__ = 2; i__ <= 6; ++i__) {
        ic = *(unsigned char *)&subnam[i__ - 1];

So it is again operating in unallocated memory and valgrind's memory 
checker will spew out tons of errors even on the test programs. If I 
compile my program against CLAPACK instead of 3.2.1 there are no 


The information in this e-mail is intended only for the person to whom it is
addressed. If you believe this e-mail was sent to you in error and the e-mail
contains patient information, please contact the Partners Compliance HelpLine 
at . If the e-mail was sent to you in 
but does not contain patient information, please contact the sender and 
dispose of the e-mail.

Lapack mailing list

<Prev in Thread] Current Thread [Next in Thread>

For additional information you may use the LAPACK/ScaLAPACK Forum.
Or one of the mailing lists, or