This Week on p5p 2000/11/07

Nov 7, 2000 by Simon Cozens

Notes

You can subscribe to an email version of this summary by sending an empty message to p5p-digest-subscribe@plover.com.

Please send corrections and additions to simon@brecon.co.uk

Apologies for the slightly late appearance of this report; I aim to get them out every Monday, but I’m hoping you were all so distracted by the US election that you didn’t notice yet. This week was pretty heavy, reaching either 300 or 550 messages depending on whether you count unique mails or duplicates. However, there wasn’t much in the way of hugely interesting content.

Error number parsing

An innocent-looking patch to t/lib/io_multihomed.t managed to turn up some problems with Errno.pm. (Good work Casey Tweten for finally tracking that down, after what looked like a rather agonizing debugging session…)

If you didn’t know, the Errno module is automatically generated by reading the system’s errno.h file when Perl is being built. However, it looks like some people’s systems and libc implementations use macros that are too difficult for Perl to parse automatically, and this meant that some error constants (you know, like EINPROGRESS and ETOOSTUPID and so on.) were not getting picked up. (Tom Hughes noticed this on RedHat 7.0 as well.) The solution is to use the -dM flag to gcc; there’s not much we can do for non-gcc right now.

VMS hackery

There was a lot of work on VMS this week: firstly, in the area of file locking. Peter Prymmer reported that t/lib/st-lock.t failed since VMS doesn’t really have locking. Peter Farley piped up and said that this was also the case on DOS and DJGPP, and the work-around there was to null-op the locking tests. Andy Dougherty mentioned that a permanent fix would be to define a d_fcntl_can_lock Configure variable to determine whether or not fcntl is any use. Craig Berry had suggested this idea before; Andy provided the patch.

Peter also noticed that one of Jarkko’s patches had broken the POSIX module; there were also some problems with erronous output confusing the test harnesses, so that the tests were passing but were still reporting failures.

After all that, Perl on VMS now passes all tests, and there was much rejoicing!

The (f)crypt of mystery

Richard Proctor is trying to compile Perl on RiscOS (and take over the RiscOS pumpkin) however is having problems in that fcrypt isn’t prototyped on that system. He tried to force the issue with a couple of casts, but Jarkko wasn’t impressed; the Right Way to do it is to have a separate riscos/ directory and put the platform-specific things in there. Nicholas Clark remarked that the [fcrypt] support was “weird”:

There are 4 references to FCRYPT but nothing anywhere (even in a port subdirectory) defines the macro. The macro isn’t of the usual HAS_ or I_ forms. Does anyone know where it originates?

Nobody did, which is… well, weird. However, we found out where Riscos’s UnixLib got its fcrypt implementation from.

Andy Dougherty suggested that the other right way to do it would be to define (and test for) a configure symbol d_fcrypt_proto which then turns into HAS_FCRYPT_PROTO.

No patches were forthcoming.

Yet more self-ties

Randy Ray has a module ( Perl-RPM) which uses a self-tie; he found that the reference count of a self-tied object is two, where you’d expect it to be one. Alan replied that self-ties are badly broken (hey, don’t we know it…) and Jarkko announced that we could really do with someone who’s prepared to tackle this issue and get it sorted out. Randy promised to try and have a look.

Steffen Bayer suggested that you could just manually set the reference count back to one, which struck Alan as somewhat sick. Steffen responded:

IMO, this is a matter of opinion. :-)

There’s nothing fundamentally evil about setting the refcount to a lower value, because this just triggers the DESTROY() event sooner than it would normally.

But Nick noted that you can’t ensure that you’re not going to create any more references to the object during DESTROYing, so this really is fundamentally evil after all.

Rsync vs. FTP’ing the patches

Merijn Brand complained of a discrepancy between the patch archive (That’s rsync://ftp.linux.activestate.com/perl-current-diffs/ or ftp://ftp.linux.activestate.com/pub/staff/gsar/APC/perl-current-diffs) and the latest source tree. ( rsync://ftp.linux.activestate.com/perl-current/ or ftp://ftp.linux.activestate.com/pub/staff/gsar/APC/perl-current.)

Sarathy explained that

The rsync mirror is automatic and syncs with the repository every five minutes.

Updating the patch area still requires manual intervention (with all the goofiness that implies, which you’ve noted) and is typically on a daily cycle. Making this process automatic is on my tuit list, but don’t ask me when.

The thread went a little off topic into the mechanics of setting up a rsync server, but lead to a contribution to perlhack from Merijn explaining how to keep in sync with the Perl source.

Changes to README.aix

We’ve recently been telling AIX users that they need to upgrade their compilers in order to compile Perl, so Merijn send in a patch to README.aix to tell them how to do so. Read about it.

Jarkko also decided it was time we had a README.Solaris; volunteers are being sought.

The Regex Stack Problem

Sam Smith found a regular expression which will crash the engine with a segfault - further investigation showed it was the engine recursing too deeply and exceeding the maximum stack depth. Dominic Dunlop explained that it was difficult to fix this one, as writing stack checking code portably is quite a challenge, and fixing the root of the problem - changing the regex engine from recursion to iteration - is somewhat Herculean.

Dominic further explained that he had a stack checking patch but it depended on the system having the BSD resource limit functions getrlimit and setrlimit. He also couldn’t find a nice way of making this all play sensibly with threads. At the time, Ilya had countered that the problem should really be fixed by rewriting the engine to be iterative; Dominic had tried this, but it was very tricky and slowed the whole thing down by about 30% - this was due to the extra memory allocation of the structures that needed to be copied between levels. Jarkko came up with a few ideas, most promising being the use of a custom stack.

The work-around is to increase the process’s stack size using ulimit; it was suggested that perl should be able to use setrlimit to extend its own stack size when necessary. This was frowned upon by Jarkko - limits are imposed for a reason.

Anyone who’s got infinite patience and sanity may want to consider hacking at removing the recursion, but so far Dominic and Hugo look like the only people patient and sane enough.

Things nobody’s fixed

A few bug reports nobody’s investigated yet, for those of you with a spare minute: xsubpp truncates files

, the AUTOLOAD behaviour changed in 5.6, and UTF |= is broken.

Enjoy!

Craig Berry

Craig Berry deserves a special mention for his huge contribution to p5p this week - we saw nearly three hundred messages from him. However, on closer examination, 284 of them turned out to be the same, thanks to a malicious copy of CC Mail belonging to somewhere completely different. (It wasn’t Craig’s fault at all.)

Various

I leave you with a veritable smorgasbord of misdirected queries, test reports, FAQs, off-topic posts, and people spamming the list about how much spam there was on the list, and until next week I remain, your humble and obedient servant,

Simon Cozens

Tags

community

Feedback

Something wrong with this article? Help us out by opening an issue or pull request on GitHub