Nicholas Clark <[EMAIL PROTECTED]> writes:
>> sure if there are any non-two's complement machines out there anymore,
>
>However, as perl5 has a few 2s complement assumptions already polluting the
>source, unless we can find a 1s complement (or other) machine to test on, it
>seems sensible (to me
On Fri, Jan 05, 2001 at 11:20:06AM -0600, Garrett Goebel wrote:
> Visual Basic has been growing up too. And it's a whole lot easier to work
> with the Win32 API, COM, ADSI, COM, etc. than Perl.
This is now firmly off-topic, but... DevKit?
--
UNIX was not designed to stop you from doing stupid t
On Wed, Dec 27, 2000 at 01:00:14PM -0500, Dan Sugalski wrote:
> At 09:07 AM 12/27/00 -0800, Benjamin Stuhl wrote:
> >--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > Why? For variables, math is math--2+2=4 regardless of
> > > whether you're one or
> > > two's complement, or BCD-encoded, or use t
> At 12:29 AM 1/5/01 -0500, Bradley M. Kuhn wrote:
> >Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >
> > > I'm beginning to loathe software licenses in a *big* way, and I'm a half
> > > step away from saying to hell with it all and going fully public domain.
> > > (Or at least pushing for it, as I do
> On Fri, 5 Jan 2001, Bradley M. Kuhn wrote:
>
> > I personally think that the relying on LGPL'ed code is completely
> > reasonable. Some will disagree, so we need to come to a consensus on this
> > as a community.
Andy Dougherty <[EMAIL PROTECTED]> wrote:
> 1. What are the consequences for t
From: Dan Sugalski [mailto:[EMAIL PROTECTED]]
>
> Screw Visual Basic, Perl should be the scripting language of
> choice for, well, everything! :)
Well... then someone needs to make it easier to dynamically access the Win32
API from Perl.
Visual Basic has been growing up too. And it's a whole l
At 09:11 AM 1/5/01 -0600, Jarkko Hietaniemi wrote:
>On Fri, Jan 05, 2001 at 09:42:44AM -0500, Andy Dougherty wrote:
> > On Fri, 5 Jan 2001, Bradley M. Kuhn wrote:
> >
> > > I personally think that the relying on LGPL'ed code is completely
> > > reasonable. Some will disagree, so we need to come t
At 12:29 AM 1/5/01 -0500, Bradley M. Kuhn wrote:
>Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > I'm beginning to loathe software licenses in a *big* way, and I'm a half
> > step away from saying to hell with it all and going fully public domain.
> > (Or at least pushing for it, as I don't control
On Fri, Jan 05, 2001 at 09:42:44AM -0500, Andy Dougherty wrote:
> On Fri, 5 Jan 2001, Bradley M. Kuhn wrote:
>
> > I personally think that the relying on LGPL'ed code is completely
> > reasonable. Some will disagree, so we need to come to a consensus on this
> > as a community.
>
> There are ac
On Fri, 5 Jan 2001, Bradley M. Kuhn wrote:
> I personally think that the relying on LGPL'ed code is completely
> reasonable. Some will disagree, so we need to come to a consensus on this
> as a community.
There are actually a couple of different mostly-independent issues, but
yes, we'll need to
On Fri, Jan 05, 2001 at 12:38:54PM +, Nicholas Clark wrote:
> On Tue, Jan 02, 2001 at 12:00:19PM -0500, Dan Sugalski wrote:
> > I'm going to try really hard to avoid that particular pitfall, if for no
> > other reason than you can set things on the VMS C compilers such that you
> > have 64-b
On Tue, Jan 02, 2001 at 12:00:19PM -0500, Dan Sugalski wrote:
> I'm going to try really hard to avoid that particular pitfall, if for no
> other reason than you can set things on the VMS C compilers such that you
> have 64-bit pointers and 32-bit ints by default. (Takes some work, but it's
> do
"Bradley M. Kuhn" <[EMAIL PROTECTED]> wrote:
> > Liceses. Bletch.
> Don't blame the licenses, blame the copyright law that makes them an
> unfortunate necessity in many cases.
And the thieves who steal the intellectual property and claim it as their
own turf in the first place.
What are we ta
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I'm beginning to loathe software licenses in a *big* way, and I'm a half
> step away from saying to hell with it all and going fully public domain.
> (Or at least pushing for it, as I don't control perl's licensing terms)
Public domain has it's own t
Andy Dougherty <[EMAIL PROTECTED]> wrote:
> (Does the LPGL and the existence of fgmp make it ok to distribute the
> interface/XS code and rely on the end user to install gmp if they so
> choose? Ick. I hate licensing problems.)
This is actually one of the reasons I'd like to see the licensing
Dan Sugalski wrote:
>
> At 10:14 AM 1/2/01 +, David Mitchell wrote:
> >Nick Ing-Simmons <[EMAIL PROTECTED]> wrote
> > > BigFloat could well build on BigInt for its "mantissa" and have another
> > > int-of-some-kind as its exponent. We don't need to pack it tightly
> > > so we should probably
On Tue, 2 Jan 2001, Dan Sugalski wrote:
> At 12:34 PM 1/2/01 -0500, Andy Dougherty wrote:
> >If you want to experiment with modifying perl5's bigints and bigfloats
> >with a tuned library to get an idea of how much speed we're talking about,
> >gmp is probably the best bet to get a good estimate
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> No, I don't think so. In this case, the natural word size really
DS> is 16 bits, regardless of what's transparent to the
DS> programmer. (Just as 32-bit integers seem fastest for many things
DS> on Alphas, despite the fact that it
At 12:58 PM 1/2/01 -0500, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> At 12:43 PM 1/2/01 -0500, Uri Guttman wrote:
> >>
> >> which OS? rt-11 was my favorite!
>
> DS> RSTS/E, of course. If for no other reason than I've never used
> DS> RT-11 or RSX.
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> At 12:43 PM 1/2/01 -0500, Uri Guttman wrote:
>>
>> which OS? rt-11 was my favorite!
DS> RSTS/E, of course. If for no other reason than I've never used
DS> RT-11 or RSX. (Well, unless you count VMS in as an RSX variant...)
DS
At 12:34 PM 1/2/01 -0500, Andy Dougherty wrote:
>If you want to experiment with modifying perl5's bigints and bigfloats
>with a tuned library to get an idea of how much speed we're talking about,
>gmp is probably the best bet to get a good estimate with the least amount
>of effort (though it doesn
At 12:43 PM 1/2/01 -0500, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> sure I could do it on a PDP-11, with it's 64Kwords of I&D
> DS> space. Probably not the baseline, all-C version of the source, but
> DS> perl nonetheless.
>
>that would warm the nost
At 12:41 PM 1/2/01 -0500, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> I was thinking of chips like the 68008, which had a 16-bit data
> DS> bus. While the native word size was 32 bits, fetching one took two
> DS> trips out to memory. Done automagically
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
JH> None right now but then again it's my early morning precoffee
JH> brain... Are there any places with 32b ints and 16b ptrs? If so,
JH> casting ints to pointers and back would be even more debatable
JH> than usual.
having b
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> sure I could do it on a PDP-11, with it's 64Kwords of I&D
DS> space. Probably not the baseline, all-C version of the source, but
DS> perl nonetheless.
that would warm the nostalgic cockles of my heart. :)
which OS? rt-11 was my fa
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> I was thinking of chips like the 68008, which had a 16-bit data
DS> bus. While the native word size was 32 bits, fetching one took two
DS> trips out to memory. Done automagically for you by the chip's
DS> circuitry so you didn't h
On Sat, 30 Dec 2000, Andy Dougherty wrote:
> > >Anyone know of a good bigint/bigfloat library whose terms are such that we
> > >can just snag the source and use it in perl?
> There's a clone of the GPL one that was written specifically to avoid GPL
> issues. I'll try to dig up more references
> >None right now but then again it's my early morning precoffee brain...
> >Are there any places with 32b ints and 16b ptrs? If so, casting ints
> >to pointers and back would be even more debatable than usual.
>
> I'm going to try really hard to avoid that particular pitfall, if for no
> other
At 07:33 AM 1/2/01 -0600, Jarkko Hietaniemi wrote:
>On Tue, Jan 02, 2001 at 07:26:39AM -0500, Dan Sugalski wrote:
> > At 01:10 PM 12/31/00 -0600, Jarkko Hietaniemi wrote:
> > > > but you seem to agree that porting to most embedded type systems is
> more
> > > > of an OS (and testing!) issue than
At 09:42 AM 1/2/01 -0500, Andy Dougherty wrote:
>On Tue, 2 Jan 2001, Dan Sugalski wrote:
>
> > that got wedged into an 8K address space with overlays...) but I'm pretty
> > sure I could do it on a PDP-11, with it's 64Kwords of I&D space. Probably
> > not the baseline, all-C version of the source,
On Tue, 2 Jan 2001, Dan Sugalski wrote:
> that got wedged into an 8K address space with overlays...) but I'm pretty
> sure I could do it on a PDP-11, with it's 64Kwords of I&D space. Probably
> not the baseline, all-C version of the source, but perl nonetheless.
Oh, then perhaps we should put
On Tue, Jan 02, 2001 at 07:26:39AM -0500, Dan Sugalski wrote:
> At 01:10 PM 12/31/00 -0600, Jarkko Hietaniemi wrote:
> > > but you seem to agree that porting to most embedded type systems is more
> > > of an OS (and testing!) issue than compilation. if other complex enough
> >
> >I think there are
At 12:13 PM 12/31/00 -0600, Jarkko Hietaniemi wrote:
> > Yeak, I know a lot of the old 8 and 16 bit chips are in use as control
> > devices places. Those are the ones I'm thinking about. (Not that hard, but
> > I don't want to rule them out needlessly)
>
>Yeah! I want to dust off my trusty old Z8
At 01:10 PM 12/31/00 -0600, Jarkko Hietaniemi wrote:
> > but you seem to agree that porting to most embedded type systems is more
> > of an OS (and testing!) issue than compilation. if other complex enough
>
>I think there are true limits imposed by the more limited CPUs like
>address space. I th
At 10:14 AM 1/2/01 +, David Mitchell wrote:
>Nick Ing-Simmons <[EMAIL PROTECTED]> wrote
> > BigFloat could well build on BigInt for its "mantissa" and have another
> > int-of-some-kind as its exponent. We don't need to pack it tightly
> > so we should probably avoid IEEE-like hidden MSB. The s
At 11:58 PM 1/1/01 +, Tom Hughes wrote:
>In message <[EMAIL PROTECTED]>
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>
> > At 09:48 PM 12/30/00 +, Nick Ing-Simmons wrote:
> >
> > >ARM7/ARM9 are both 32-bit
> > >MIPS has both 32-bit and 64-bit variants.
> >
> > That's good. Though do
Nick Ing-Simmons <[EMAIL PROTECTED]> wrote
> BigFloat could well build on BigInt for its "mantissa" and have another
> int-of-some-kind as its exponent. We don't need to pack it tightly
> so we should probably avoid IEEE-like hidden MSB. The size of exponent
> is one area where "known range of in
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 09:48 PM 12/30/00 +, Nick Ing-Simmons wrote:
>
> >ARM7/ARM9 are both 32-bit
> >MIPS has both 32-bit and 64-bit variants.
>
> That's good. Though do either of them have 16-bit data busses?
If you ignore thum
Dan Sugalski <[EMAIL PROTECTED]> writes:
>> >That's fine. I was thinking of smaller processors that might be used in
>> >embedded apps and such. (I'm also not sure what's the most efficient
>> >integer representation on things like the ARM microprocessors are)
>>
>>ARM7/ARM9 are both 32-bit
>>MIPS
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
JH> An OS problem and a build environment (cross-compilation, yuk)
JH> problem. I once managed to compile miniperl (5.005) for Chorus.
JH> I'm about to unearth the cross-compilation changes I had to make to
JH> get that working.
> JH> An OS problem and a build environment (cross-compilation, yuk)
> JH> problem. I once managed to compile miniperl (5.005) for Chorus.
> JH> I'm about to unearth the cross-compilation changes I had to make to
> JH> get that working. (You thought Configure was hairy enough already?
>
> "JH" == Jarkko Hietaniemi <[EMAIL PROTECTED]> writes:
>> maybe some of us should go to an rtos/embedded show and ask around "how
>> often is perl requested?"
JH> Perl already exists for QNX, though of course QNX most often runs on x86s.
JH> Some might consider EPOC to be an embedde
> maybe some of us should go to an rtos/embedded show and ask around "how
> often is perl requested?"
Perl already exists for QNX, though of course QNX most often runs on x86s.
Some might consider EPOC to be an embedded OS (running on ARMs). But I
have had Perl requested for VxWorks (and of cour
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> That's good. Though do either of them have 16-bit data busses?
>> DSPs are more messy.
DS> That's probably a bit too specialized a piece of hardware to worry
DS> about. Unlss things have changed lately, they're not really
DS>
> Yeak, I know a lot of the old 8 and 16 bit chips are in use as control
> devices places. Those are the ones I'm thinking about. (Not that hard, but
> I don't want to rule them out needlessly)
Yeah! I want to dust off my trusty old Z80 boxes :-)
On a more serious note: recently a company ann
At 08:05 PM 12/30/00 -0500, Andy Dougherty wrote:
>On Sat, 30 Dec 2000, Nick Ing-Simmons wrote:
>
> > Dan Sugalski <[EMAIL PROTECTED]> writes:
> > >
> > >Anyone know of a good bigint/bigfloat library whose terms are such
> that we
> > >can just snag the source and use it in perl?
> >
> > There wa
At 09:48 PM 12/30/00 +, Nick Ing-Simmons wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> >At 01:05 PM 12/29/00 +, Nick Ing-Simmons wrote:
> >>Dan Sugalski <[EMAIL PROTECTED]> writes:
> >> >
> >> >I'm reasonably certain that all platforms that perl will ultimately
> run on
> >> >can mus
On Sat, 30 Dec 2000, Nick Ing-Simmons wrote:
> Dan Sugalski <[EMAIL PROTECTED]> writes:
> >
> >Anyone know of a good bigint/bigfloat library whose terms are such that we
> >can just snag the source and use it in perl?
>
> There was some traffic on gcc list recently about a GNU one (presumably G
Dan Sugalski <[EMAIL PROTECTED]> writes:
>At 01:05 PM 12/29/00 +, Nick Ing-Simmons wrote:
>>Dan Sugalski <[EMAIL PROTECTED]> writes:
>> >
>> >I'm reasonably certain that all platforms that perl will ultimately run on
>> >can muster hardware support for 16-bit integers.
>>
>>Hmm, most modern RI
Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>Anyone know of a good bigint/bigfloat library whose terms are such that we
>can just snag the source and use it in perl?
There was some traffic on gcc list recently about a GNU one (presumably GPL
only).
>I don't really care to write
>the code for di
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Anyone know of a good bigint/bigfloat library whose terms are such
DS> that we can just snag the source and use it in perl? I don't
DS> really care to write the code for division, let alone the
DS> transcendental math ops...
well
At 01:15 PM 12/29/00 +, Nick Ing-Simmons wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> >
> >BigInt and BigFloat are both pure perl, and as such their speed leaves a
> >*lot* to be desired. Fixing that (at least yanking some of it to XS) has
> >been on my ToDo list for a while, but other s
At 01:05 PM 12/29/00 +, Nick Ing-Simmons wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> >
> >I'm reasonably certain that all platforms that perl will ultimately run on
> >can muster hardware support for 16-bit integers.
>
>Hmm, most modern RISCs are very bad at C-like 16-bit arithmetic - t
At 12:56 PM 12/29/00 +, Nick Ing-Simmons wrote:
>Dan Sugalski <[EMAIL PROTECTED]> writes:
> >
> >Strings can be of three types--binary data, platform native, and UTF-32.
> >No, we are not messing around with UTF-8 or 16, nor are we messing with
> >EBCDIC, shift-JIS, or any of that stuff.
>
>I
Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>BigInt and BigFloat are both pure perl, and as such their speed leaves a
>*lot* to be desired. Fixing that (at least yanking some of it to XS) has
>been on my ToDo list for a while, but other stuff keeps getting in the
>way... :)
My own "evolutionary
Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>I'm reasonably certain that all platforms that perl will ultimately run on
>can muster hardware support for 16-bit integers.
Hmm, most modern RISCs are very bad at C-like 16-bit arithmetic - they have
a tendency to widen to 32-bits.
>I also expect th
Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>Strings can be of three types--binary data, platform native, and UTF-32.
>No, we are not messing around with UTF-8 or 16, nor are we messing with
>EBCDIC, shift-JIS, or any of that stuff.
I don't understand that in the light of supporting "platform n
On Wed, 27 Dec 2000, Dan Sugalski wrote:
> I honestly can't think of any reason why the internal representation of an
> integer matters to the outside world, but if someone can, do please
> enlighten me. :)
Passing parameters to library functions via extensions is tricky no matter
how you do i
On Wed, 27 Dec 2000, Dan Sugalski wrote:
> As for types presented to extensions, we can certainly provide I8, I16,
> I32, and friends.
But we can't guarantee that every platform has integral types of those
sizes. For example, in perl5, I32 is sometimes 32 bits, and sometimes 64
bits. Some Cra
At 09:11 AM 12/28/00 -0800, Peter Buckingham wrote:
>Dan Sugalski wrote:
> > And, unless Larry objects, I feel that all vtable methods should have
> > the option of going with a 'scalar native' form if the operation if it's
> > determined at runtime that two scalars are the same type, though this
Dan Sugalski wrote:
> And, unless Larry objects, I feel that all vtable methods should have
> the option of going with a 'scalar native' form if the operation if it's
> determined at runtime that two scalars are the same type, though this is
> optional and bay be skipped for cost reasons. (Doing
At 11:07 AM 12/28/00 +, David Mitchell wrote:
>Daniel Chetlin <[EMAIL PROTECTED]> wrote:
> > What is it about automatic conversion to bigints (done well) that scares
> > you?
>
>Well, consider the following perl5 code:
>
>sub factorial {
> my $n = shift;
> my ($f,$i) = (1,0);
>
Daniel Chetlin <[EMAIL PROTECTED]> wrote:
> What is it about automatic conversion to bigints (done well) that scares
> you?
Well, consider the following perl5 code:
sub factorial {
my $n = shift;
my ($f,$i) = (1,0);
$f *= ++$i while $i < $n;
$f;
}
Someone might b
At 06:15 PM 12/27/00 -0500, Uri Guttman wrote:
> > "DC" == Daniel Chetlin <[EMAIL PROTECTED]> writes:
>
> DC> Which of these two behaviors do you find more useful:
>
> DC> [~] $ perl -le'$c=1;$c*=$_ for (2..170);print $c'
> DC> 7.25741561530799e+306
> DC> [~] $ perl -le'$c=1;$c*=
> "DC" == Daniel Chetlin <[EMAIL PROTECTED]> writes:
DC> Which of these two behaviors do you find more useful:
DC> [~] $ perl -le'$c=1;$c*=$_ for (2..170);print $c'
DC> 7.25741561530799e+306
DC> [~] $ perl -le'$c=1;$c*=$_ for (2..171);print $c'
DC> inf
i am not worried abo
At 01:48 PM 12/27/00 -0800, Damien Neil wrote:
>On Wed, Dec 27, 2000 at 04:17:21PM -0500, Dan Sugalski wrote:
> > The issue isn't support, it's efficiency. Since we're not worrying about
> > loss of precision (as we will be upconverting as needed) the next issue is
> > speed, and that's where we w
At 04:08 PM 12/27/00 -0500, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> The semantics haven't been set down either from a perl or internals
> DS> standpoint yet. Perl level is Larry's problem, internals is ours.
> Luckily
> DS> they can be hammered ou
At 01:31 PM 12/27/00 -0800, Daniel Chetlin wrote:
>On Wed, Dec 27, 2000 at 04:08:00PM -0500, Uri Guttman wrote:
> > i can see things changing very easily. but to me, how perl handles
> > overflow is a language semantic as much as implementation. in 5 it is
> > well defined (ilya not withstanding)
On Wed, Dec 27, 2000 at 04:17:21PM -0500, Dan Sugalski wrote:
> The issue isn't support, it's efficiency. Since we're not worrying about
> loss of precision (as we will be upconverting as needed) the next issue is
> speed, and that's where we want things to be in a platform convenient size.
I t
On Wed, Dec 27, 2000 at 04:08:00PM -0500, Uri Guttman wrote:
> i can see things changing very easily. but to me, how perl handles
> overflow is a language semantic as much as implementation. in 5 it is
> well defined (ilya not withstanding) and you are talking bigint stuff
> which scares me. i don
At 11:21 AM 12/27/00 -0800, Damien Neil wrote:
> >On Wed, Dec 27, 2000 at 02:06:45PM -0500, Hildo Biersma wrote:
>I seriously doubt Perl will ever run on an architecture too small
>to provide a 32-bit type. I am certain it will never run on an
>architecture with no 16-bit type.
I'm reasonably ce
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> The semantics haven't been set down either from a perl or internals
DS> standpoint yet. Perl level is Larry's problem, internals is ours. Luckily
DS> they can be hammered out mostly independently.
i can see things changing very e
At 02:15 PM 12/27/00 -0500, Uri Guttman wrote:
> > "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> Our integers will be generally unbounded in size--what I want is
> DS> for the platform people to have the option of choosing a fast
> DS> version of integer scalars that can be us
On Wed, Dec 27, 2000 at 02:51:57PM -0500, Hildo Biersma wrote:
> This seems likely, but we must take care not to take these assumptions
> too far. For example, (and this is not realted to this discussion),
> pointers may well be smaller than integers (MVS defines 32-bit ints and
> 31-bit pointers
Damien Neil wrote:
>
> On Wed, Dec 27, 2000 at 02:06:45PM -0500, Hildo Biersma wrote:
> > I don't recall the bit sizes to be in ANSI C. Which paragraph is that
> > in?
>
> You need to deduce the bit sizes, as the standard doesn't speak in
> terms of bits. I don't have a copy of C89 available,
On Wed, Dec 27, 2000 at 02:06:45PM -0500, Hildo Biersma wrote:
> I don't recall the bit sizes to be in ANSI C. Which paragraph is that
> in?
You need to deduce the bit sizes, as the standard doesn't speak in
terms of bits. I don't have a copy of C89 available, but section
5.2.4.2.1 defines the
> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
DS> Our integers will be generally unbounded in size--what I want is
DS> for the platform people to have the option of choosing a fast
DS> version of integer scalars that can be used when appropriate, and
DS> switching to the slower b
At 10:56 AM 12/27/00 -0800, Damien Neil wrote:
>I'd be in favor of defining Perl's "native int" type to be at least
>32 bits long. I would recommend against using the compiler's default
>int type in all cases, as there are compilers which define int as 16
>bits for backwards compatability reasons
Damien Neil wrote:
>
> On Wed, Dec 27, 2000 at 10:46:03AM -0500, Philip Newton wrote:
> > So a native int could be 8 bits big? I think that's allowed according to
> > ANSI.
>
> ANSI/ISO C states:
> char <= short <= int <= long
>
> char >= 8 bits
> short >= 16 bits
> int >= 16 bits
>
On Wed, Dec 27, 2000 at 10:46:03AM -0500, Philip Newton wrote:
> So a native int could be 8 bits big? I think that's allowed according to
> ANSI.
ANSI/ISO C states:
char <= short <= int <= long
char >= 8 bits
short >= 16 bits
int >= 16 bits
long >= 32 bits
C99 adds "long long", w
At 09:07 AM 12/27/00 -0800, Benjamin Stuhl wrote:
>--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 08:02 AM 12/26/00 -0800, Benjamin Stuhl wrote:
> > >Thus spake the illustrious Dan Sugalski <[EMAIL PROTECTED]>:
> > > > For integers, we have two types, platform native, and
> > > > bigint. No gu
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 08:02 AM 12/26/00 -0800, Benjamin Stuhl wrote:
> >Thus spake the illustrious Dan Sugalski <[EMAIL PROTECTED]>:
> > > For integers, we have two types, platform native, and
> > > bigint. No guarantees
> > > are made as to the size of a native int. big
At 10:46 AM 12/27/00 -0500, Philip Newton wrote:
>On Mon, 25 Dec 2000, Dan Sugalski wrote:
>
> > For integers, we have two types, platform native, and bigint. No
> guarantees
> > are made as to the size of a native int. bigints can be of any size.
>
>So a native int could be 8 bits big?
Yup, if
On Mon, 25 Dec 2000, Dan Sugalski wrote:
> For integers, we have two types, platform native, and bigint. No guarantees
> are made as to the size of a native int. bigints can be of any size.
So a native int could be 8 bits big? I think that's allowed according to
ANSI. Not very useful, though. W
At 08:02 AM 12/26/00 -0800, Benjamin Stuhl wrote:
>Thus spake the illustrious Dan Sugalski <[EMAIL PROTECTED]>:
> > For integers, we have two types, platform native, and
> > bigint. No guarantees
> > are made as to the size of a native int. bigints can be
> > of any size.
>
>I'm not sure about the
Thus spake the illustrious Dan Sugalski <[EMAIL PROTECTED]>:
> Okay, here's what I'm currently thinking of for standard
> representations of
> integers, numbers, strings, and (possibly) complex data.
> These are not
> necessarily indicative of how the data'
Okay, here's what I'm currently thinking of for standard representations of
integers, numbers, strings, and (possibly) complex data. These are not
necessarily indicative of how the data's stored in scalars (or hashes or
arrays), merely the types that will need to be dealt with
87 matches
Mail list logo
