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.
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.
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.
- Damien
