This Week on p5p 1999/11/28

Nov 28, 1999 by Mark-Jason Dominus

Notes

This report is very late, because I was in London from 26–29 November, and then when I got back I had to finish preparing class materials for a class I was teaching in Chicago from 6–8 December, and when I got back from that I had to prepare class materials for a class I was teaching in New York from 14–16 December. Then I had to recover. Now I’m going to try to catch up on reports. My apologies for the delay.

New Meta-Information

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 mjd-perl-thisweek-YYYYMM@plover.com where YYYYMM is the current year and month.

Thread Model Discussion

In the last report, I posted an explanation by Dan Sugalski of the current threading model and the new one that would be used in 5.005_53. (Here it is.)

This reopened debates about the feasibility of the new model, and Dan, Sarathy, and Ilya had a medium-long discussion about it. The debate centered around how much stuff gets cloned when you fork a new thread/process. Here’s my probably-too-brief summary: Under the new model, when you start a new thread, the Perl stack is cloned and each thread gets a separate clone. But you can also request fork()-like semantics, in which case all global variables also get cloned. This will allow forkless Windows platforms to emulate fork() with threads. In either case, the op tree (which is read-only) is shared between threads.

The debate centered around the largeness of the amount of data that would need to be cloned. Sarathy claims that even in the fork case the op tree outeighs the global data by a factor of 8.

The whole discussion was very interesting and is recommended reading. The top of the discussion is here.

This and the ensuing discussion is worth reading if you are interested in the changes in Perl’s threading model.

Discussion of Line Disciplines Continues

Much interesting discussion about line disciplines continues, this time in the context of having <> and chomp() behave properly, even when you have a remote-mounted NT fileststem where the files have \r\n-terminated lines. Goal: Perl should do the `right thing’ regardless of where the file is located. The subtext here is that Perl should also do the `right thing’ when reading from an ISO-Latin-1 file, an EUC-KR encoded file in Korean, or a SHIFT-JIS encoded file in Japanese.

Larry: I expect people to expect Perl to do the right thing.

Earlier Discussion

Still Earlier Discussion

Guess What

Shadow Passwords

Jochen Wiedmann compained abuot the support for shadow password files. If your vendor supprots them transparently via the usual getpw* calls, Perl supports them too; otherwise you’re out of luck. In fact this is a frequently asked question: How to get the shadow password?

There are at least two schools of thought on this. School of thought #1 is that when you make a getpw* call, you should get back the usual seven items, except that if you’re on a system with shadow passwords and you’re not rnuning as root, you get back x or * or some such instead of the real password; thus no new interface is required. The author of the man page (see perlfunc/getpwent) apparently subscribes to this school of thought.

School of thought #2 is that getpw* should always return a password of x, and instead there should be special calls, probably named getsp* or something similar, for reading the shadow password file.

Advantages of school #1: No program needs to be rewritten or even modified when you switch from traditional password style to shadow passwords. Advantages of school #2: No program will get the passwords written into its memory unless it specifically asks for them, regardless of whether or not it happens to be run by root; having programs suddenly become riskier just because they are running as root is a Bad Thing.

Anyway, Sarathy reports that as of 5.005_57, Perl has gone entirely over to school #1 and will emulate that behavior even if you are on a system that belongs to school #2. If you call any of Perl’s getpw* functions, and your program is running as root, then Perl will make a getsp* call to fill in the password as if it had been returned by the getpw* call in the first place.

I seem to remember that debate on whether or not this was advisable continued the following week, so I’ll follow up in the next report.

Bugs in NT Perl Sockets?

Phil Pfeiffer posted an interesting analysis of peculiarities of Perl network sockets under NT. I found these interesting, but there was no discussion. Of course, it is probably NT’s fault, but it would be nice to see these fixed anyway. As Larry has said ``The Golden Gate wasn’t our fault either, but we still put a bridge across it.” Read it.

Run Out of File Descriptors

Yossi Klein was puzzled because Perl limited him to 256 open files, even when he used sysopen to try to open the files without using the Standard I/O library. Of course, even if you use sysopen, it then takes the file descriptor that it gets from the system and attaches it to a filehandle, and that means it uses fdopen to create the stdio stream structure, and there’s Standard I/O again.

Lexical Variable Leak

Barrie Slaymaker reported a bug in 5.005_61 in which a lexical variable in one file leaked into a different file that was being processed by do.

Control-Backslash

The discussion about semantics of control-backslash in a double-quoted string continued much longer than it should have, with the original correspondent proposing every possible alternative set of rules, and Ilya Zakharevich pointing out what was wrong with all of them. The original querent finally gave in.

Bitwise Operators

Someone was caught by the changed behavior of the & operator between Perl 4 and Perl 5. Tom Christiansen posted a clear explanation. For some reason this topic was omitted from perltrap.

The discussion then turned towards how you can tell whether or not a string has ever been used in a numeric context. Larry suggested:

    length($x & "")

Tom Phoenix posted a patch to add an explanation to perltrap.

Taint Bug?

David Muir Sharnoff appears to have found a case where doing a match and copying data into $1 yields a tainted value instead of an untainted one. There was no discussion and I did not see a patch. (I should mention that starting this week I began to watch the patch FTP directory, but because of my travel schedule I did not have time to understand the patches.)

next Outside a Block

Someone complained that

    map { next if ... } ... ;

yields the error message `Can’t “next” outside a block’. He claimed that the message was bad because clearly the next is in a block. Larry agreed that it should say `loop’ instead of `block’. I didn’t see a patch, however.

Quiet List

Traffic was low for a while, so Nat Torkington sent out a ping message:

Nat: Just testing whether all of p5p has fallen quiet, or whether the mailing list manager is constipated. Kurt Starsinic: The perl5-porters are on vacation, and will be until noon on November 25. If your need is urgent, please contact python-help@python.org. Thank you.

Various

A large collection of bug reports, bug fixes, non-bug reports, questions, answers, spam, and a small amount of flamage.

Until next time (probably Tuesday or Wednesday) I remain, your humble and obedient servant,

Mark-Jason Dominus

Tags

community

Feedback

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