From warren-odom@stenocall.com

  my $sum = LOCK_EX + LOCK_NB;
  my $or = LOCK_EX | LOCK_NB;
  print "$exclusive + $non_block = $sum\n";
  print "$exclusive | $non_block = $or\n";

prints the following results​:

  2 + 4 = 2
  2 | 4 = 6

Both Randal Schwartz and Larry Rosler correctly diagnosed the problem.
Here's Randal's (edited) description​:

Watch​:

use Fcntl qw(LOCK_EX LOCK_NB);

my $ex = LOCK_EX;
my $nb = LOCK_NB;

for (split /\n/, <<'END') {
LOCK_EX
LOCK_NB
$ex
$nb
LOCK_EX + LOCK_NB
$ex + $nb
LOCK_NB + LOCK_EX
$nb + $ex
LOCK_EX() + LOCK_NB()
LOCK_EX(+ LOCK_NB)
END
print "$_ is ", eval $_, "\n";
}

Which prints​:

LOCK_EX is 2
LOCK_NB is 4
$ex is 2
$nb is 4
LOCK_EX + LOCK_NB is 2
$ex + $nb is 6
LOCK_NB + LOCK_EX is 4
$nb + $ex is 6
LOCK_EX() + LOCK_NB() is 6
LOCK_EX(+ LOCK_NB) is 2

Ahh... look at the last two. They give away the secret. LOCK_EX is
defined as "sub LOCK_EX { 2 }". So "LOCK_EX + LOCK_NB" is being
parsed as "LOCK_EX(+ LOCK_NB)" - a unary plus operator in front of the
ignored argument!

These subs *should* have been prototyped as "sub LOCK_EX () {2}". But
no.

When I Emailed Randal to ask whether this has been reported, I didn't
understand his reply (he referred to a followup message that as far as I can
see doesn't seem to exist, or at least my news server isn't showing it). So
rather than take up any more of his time, I'm just going ahead and reporting
it as a Perl bug to you.

  -- Warren

From @RandalSchwartz

"Warren" == Warren Odom <warren-odom@​stenocall.com> writes​:

Warren> When I Emailed Randal to ask whether this has been reported, I
Warren> didn't understand his reply (he referred to a followup message
Warren> that as far as I can see doesn't seem to exist, or at least my
Warren> news server isn't showing it). So rather than take up any
Warren> more of his time, I'm just going ahead and reporting it as a
Warren> Perl bug to you.

It wasn't my reply. The reason it cannot be fixed is that those
constants are AUTOLOADed, which means that they cannot have a
prototype of any consequence.

Not fixable without major surgery.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@​stonehenge.com> <URL​:http​://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

From [Unknown Contact. See original ticket]

Warren> When I Emailed Randal to ask whether this has been reported, I
Warren> didn't understand his reply (he referred to a followup message
Warren> that as far as I can see doesn't seem to exist, or at least my
Warren> news server isn't showing it). So rather than take up any
Warren> more of his time, I'm just going ahead and reporting it as a
Warren> Perl bug to you.

<<It wasn't my reply.>>

Didn't mean to imply it was. There may be something wrong with my ISP's
news server-the other day, in another thread in another newsgroup, some
messages seemed to appear out of nowhere, long after they were written. I
still can see no newsgroup message (from anyone) saying it can't be fixed.

<<The reason it cannot be fixed is that those
constants are AUTOLOADed, which means that they cannot have a
prototype of any consequence.
Not fixable without major surgery.>>

Oh, well, I'm sorry to hear that. After you said in the newsgroup they
should be prototyped differently, I took that as gospel. And I recall you
mentioned autoloading in your first mail, but I'm not familiar with it so
that didn't mean anything to me.

Maybe this could be put on the wishlist for possible resolution sometime
when doing surgery anyway.

  -- Warren

From @gbarr

On Tue, Jan 25, 2000 at 12​:01​:48PM -0800, Randal L. Schwartz wrote​:

It wasn't my reply. The reason it cannot be fixed is that those
constants are AUTOLOADed, which means that they cannot have a
prototype of any consequence.

Sure they can.

sub LOCK_NB ();

is legal and will do what is needed.

Graham.