At 08:19 AM 8/2/00 -0500, Craig A. Berry wrote:
>At 4:57 AM -0400 8/2/00, lane @ DUPHY4.Physics.Drexel.Edu wrote:
>>In article <p04320401b5ad5cc9c0e9@[192.168.56.173]>, "Craig A. Berry"
>><[EMAIL PROTECTED]> writes:
>> > When attempting a threaded build of perl@6409 with DEC C 6.2, it quit
>>> with the following complaint on av.c:
>> > E extern int Perl___notused
>>> 3 50254 (void)SvREFCNT_inc(sv);
>>> ..................1
>>> %CC-E-BIFPROTO, (1) In this statement, the built-in function,
>>> "__ATOMIC_INCREMENT_LONG", requires a prototype declaration from
>> > <builtins.h>.
>
>>I *know* that the __ATOMIC_(IN|DE)CREMENT_LONG is not available for
>>DECC/VAX, VMS7.1 and compiler version (*mumble*).
>>
>>We probably should use _ADAWI which is available for both VAX and AXP
>>although for some reason the number of leading underscores differ.
>>And, of course, it does words not longwords. Do we use ref counts >64K?
>
>I confess I never figured out how we get from SvREFCNT_inc to
>__ATOMIC_INCREMENT_LONG; after following the trail through three or four
>#defines I gave up and just did what the compiler told me to do. So, it's
>possible the various configure options will pull in an appropriate
>alternative on other OS/compiler/processor combinations, but I don't know
>that for sure.
This all looks like it came from a patch I threw out a while ago. I
probably missed the header file that loaded in builtins.h.
As for refcounts, they're native integers, so they can get big. It's not
hugely likely, but something like this:
foreach (1..100000) {
push @foo, \$bar;
}
would drive the refcount on $bar past the 64K limit pretty quickly.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
