Mailing List Archive

> From: Mike Stok <stok@cybercom.net>
>
> I was just trawling through the perl5.001m pp.c having responded to a
> post, and saw:
>
> case 'L':
> while (len-- > 0) {
> fromstr = NEXTFROM;
> aulong = U_L(SvNV(fromstr));
> sv_catpvn(cat, (char*)&aulong, sizeof(U32));
> }
> break;
> case 'l':
> while (len-- > 0) {
> fromstr = NEXTFROM;
> along = SvIV(fromstr);
> sv_catpvn(cat, (char*)&along, sizeof(I32));
> }
> break;
>
> around line 3200...
>
> Does this mean that perl5 thinks longs are 32 bits regardless of the
> "real" size of a long (which is 64 bits on "my" alpha)?
>
> Would it be easy to fix?
>
What's needed are pack/unpack codes for 32 bits, 64 bits and 'native
longs' where native longs are whatever size the O/S thinks longs
in its structures are.

Just 'fixing' L to be 64 bit on some platforms would not be a good fix.

Tim.

On Fri, 6 Oct 1995, Tim Bunce wrote:

> > Does this mean that perl5 thinks longs are 32 bits regardless of the
> > "real" size of a long (which is 64 bits on "my" alpha)?
> >
> > Would it be easy to fix?
> >
> What's needed are pack/unpack codes for 32 bits, 64 bits and 'native
> longs' where native longs are whatever size the O/S thinks longs
> in its structures are.
>
> Just 'fixing' L to be 64 bit on some platforms would not be a good fix.

Absolutely, what about using 'w' and 'W' for a native wide word?

Mike

--
Mike Stok | The "`Stok' disclaimers" apply.
stok@pencom.com | Pencom Systems Administration (work)
stok@cybercom.net | Cyber Access (play)
http://www.cybercom.net/~stok/ | The inevitable WWW page (?)

On Fri, 6 Oct 1995, Tom Christiansen wrote:

> I'm not sure what that is worth.
>
> Note that I added Q and q for explicit "long long" types to perl
> about 5 or 6 years ago.
>
> I'm pretty leary of pack and unpack. People think the same format
> works transparently on 8 bit 8080s as on 60 bit CDCs, and it isn't so.

I'd like the 'long' in perl to be the same as the 'long' I get from my C
compiler. I think that that would help C <-> perl "portability" on a
machine, but agree that it may mess up machine <-> machine portability
(but I'd hope that people using pack & unpack had at least half a clue,
even though experience suggests otherwise.)

Now that I've pawed over the source I see the Q & q (should this get a
mention in the perlfunc manpage?) but still think that it's adding some
haze to the relationship between perl & C longs...

Mike

--
Mike Stok | The "`Stok' disclaimers" apply.
stok@pencom.com | Pencom Systems Administration (work)
stok@cybercom.net | Cyber Access (play)
http://www.cybercom.net/~stok/ | The inevitable WWW page (?)

On Fri, 6 Oct 1995, Mike Stok wrote:

> On Fri, 6 Oct 1995, Tom Christiansen wrote:
>
> > I'm not sure what that is worth.
> >
> > Note that I added Q and q for explicit "long long" types to perl
> > about 5 or 6 years ago.
> >
> > I'm pretty leary of pack and unpack. People think the same format
> > works transparently on 8 bit 8080s as on 60 bit CDCs, and it isn't so.
>
> I'd like the 'long' in perl to be the same as the 'long' I get from my C
> compiler.

Me too.

> I think that that would help C <-> perl "portability" on a
> machine, but agree that it may mess up machine <-> machine portability

Yup. I also like having 'N' and 'V'.

> Now that I've pawed over the source I see the Q & q (should this get a
> mention in the perlfunc manpage?) but still think that it's adding some
> haze to the relationship between perl & C longs...

Well, I'm not sure that Q and q work on many systems, so I wouldn't
rush to document them :-)

There are a couple of underlying problems too.

First, I never really got in sync with Larry about the [IU]32
typedefs. His original intent was that they be exactly 32 bits on all
systems. My original intent was that they be at least 32 bits on all
systems, and probably an 'int'. (Currently, on the Cray, I32 and U32
are 64 bits.) Lots of the perl functions use I32 variables. Lots of C
library functions use 'int'. Getting all of the prototypes to happily
coexist was not fun, and I'm not too eager to revist the problem by
setting I32 to short (or whatever it would take) on some systems. On
the other hand, having I32 be something other than 32 bits might cause
problems with pack/unpack, and is certainly potentially confusing.

Second, there have been various problems reported with unsigned longs.
I know some compilers have trouble with large unsigned longs (i.e.
those with the MSB set). Sort of makes the 'unsigned' useless on
those systems, but you work with what you have.

And, of course, there can be simple bugs. If memory serves, this
thread started with a call to sv_catpvn which seemed to assume
sizeof(unsigned long) == sizeof(U32). Offhand, that doesn't look
right to me.

Andy Dougherty doughera@lafcol.lafayette.edu

> Absolutely, what about using 'w' and 'W' for a native wide word?

I'm not sure what that is worth.

Note that I added Q and q for explicit "long long" types to perl
about 5 or 6 years ago.

I'm pretty leary of pack and unpack. People think the same format
works transparently on 8 bit 8080s as on 60 bit CDCs, and it isn't so.

--tom

How about

Cc for char as in C
Ss for short as in C
Ll for long as in C
Ww for I32
Qq for I64 (quad word, gcc "long long" in 32 bit machines)

++jhi;