Explicitly reject length(NAME) with typemaps other than T_PV

[Leont]

Previously, the length operator on typemaps other than T_PV would lead to that length value not being initialized, leading to segfaults and worse. Worse yet, ExtUtils::ParseXS would silently emit this erroneous code.

For now it will at least give a clear error, in the future we should perhaps consider eliminating this limitation altogether.

• This contains a changelog entry for ExtUtils::ParseXS instead of a perldelta

[Leont]

This one caused my a bunch of grief related to #23150 before I figured out what was going on.

[iabyn]

It needs test(s) for the new error message. Other than that, I approve.

[jkeenan]

It needs test(s) for the new error message. Other than that, I approve.

Currently, in dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS/Node.pm's lookup_input_typemap(), there already exists one error condition at the point where the p.r. proposes to insert a new die. That existing die itself appears to be unexercised in the test suite.

$ ack 'default value not supported' dist/ExtUtils-ParseXS/
dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS/Node.pm
1411:            die "default value not supported with length(NAME) supplied"

Could we write tests for both conditions in this p.r.?

[Leont]

It needs test(s) for the new error message. Other than that, I approve.

Added that

[iabyn]

The first part of 001-basic.t uses a crude form of test framework. Newer tests in the file (basically the ones added by me in the last year) use a better framework. It would be better to use this new framework. Look for the "length() no matching var" test; it would be easy and better to add a new test directly after that test.

[Leont]

Yeah that is helpful. Updated the PR

[iabyn]

On Sun, Jul 27, 2025 at 03:31:09AM -0700, James E Keenan wrote: jkeenan left a comment (Perl/perl5#23479) Currently, in dist/ExtUtils-ParseXS/lib/ExtUtils/ParseXS/Node.pm's `lookup_input_typemap()`, there already exists one error condition at the point where the p.r. proposes to insert a new `die`. That existing `die` itself appears to be unexercised in the test suite. ```

That's because that condition isn't (I think) ever reached. A similar check+die is done earlier during parsing, and there *is* a test for that error. I'll add a note to self to remove the redundant check at some point.

…

-- Modern art: "That's easy, I could have done that!" "Ah, but you didn't!"

[iabyn]

This doesn't look quite right. In the '[ 1, 1, ...]', the first 1 means check stderr rather than stdout, and the second means reverse the expectation, i.e. the test passes if the pattern doesn't match (that's the bit which doesn't look right).

[Leont]

You're right. That should be fixed now.