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, but section
> 5.2.4.2.1 defines the sizes of the various integers:
>
> -- minimum value for an object of type short int
> SHRT_MIN -32767 // -(2 ** 15 - 1)
> -- maximum value for an object of type short int
> SHRT_MAX +32767 // 2 ** 15 - 1
>
> ...and so forth.
>
> > Even so, the fact that a standard may declare it, doesn't make it true.
> > I would expect embedded targets to differ from this.
>
> 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.
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)
> Furthermore, the fact that the standard declares a thing DOES make
> it true. If Perl is to be written in C, it makes sense that it
> require a compiler which at least pretends to conform to ANSI/ISO
> C. This is hardly an onerous restriction -- most compilers are
> compliant, with the exception of compilers for very-small embedded
> systems (ones where the total memory available is measured in bytes)
> and antiquated curiosities like the SunOS 4 compiler.
I have far less trust in the standards than you have. Having said that,
I can't actually name non-compliant compilers, so you're quite likely to
be right.
> Can you name specific compilers which fail to conform to the standard
> in this (or other) regards, which Perl will need to support?
>
> > That's eskewing efficiency to make sensible minimum guarantees. I'd
> > personally rather see the C compiler's native types be used, because
> > that's what the platform can do _efficiently_. Using larger types than
> > that harms perl's ability to perform well on small platforms.
>
> I am deeply dubious about Perl's ability to perform well on 80286
> (or equivalent capacity) machines under any circumstances.
I sure would like it to still work, though. On a tiny platform, I'd
rather have a slow and mimimalistic perl, than no perl at all. If a
drive for efficiency on larger platforms would preclude the use of perl
on such tiny systems (and your proposal doesn't), that would be bad.
Hildo
