Re: enable maximum integer type to be 128 bits

["Jan Beulich" <JBeulich at novell dot com>]

OK, I may lack knowledge of the C90 standard (whether this makes me a non-reasonable person is another thing). I started significantly caring for standards only when C99 was almost finished. Thus I don't even have a copy of C90 around, and so can't prove what you're saying. Still, I have no reason not to believe it's how you say. But nevertheless, this doesn't convince me. Standards aren't free of errors/omissions, and while you are concerned about breaking millions of lines of code (which make assumptions they, in my opinion, shouldn't have made, and wouldn't have to have if stdint.h would have been introduced not that late, thus leading people to use 'long' where they should have used 'intptr_t'), you also enforce new code to be written to these (broken in my way of thinking) assumptions. We, basing our types model exclusively on C99, decided to not do so, and you're basically saying that because gcc shouldn't be supported for such an environment (my interpretation of 'open source' is that the source is not only visible but also useful to everyone who cares).

Now, it seems to me that you're also missing a fundamental piece of my intentions here: I'm not trying to force on everyone a model that fully utilizes C99, yet (appearantly) breaks C90 in some way. What I instead want is the alternative of allowing such a model for those whose code can work there (once again, you're basically saying 64-bit integers on 32-bit platforms are an error, which I'll never agree to, and it's this difference in opinions which allows me but denies you to have 128-bit integers on 64-bit plaforms * see that e.g. ia64's and x86-64's ABIs even allow for such types, even through they don't require support for them * but if supported, they are to be integer types).

Jan

>>> Zack Weinberg <zack@codesourcery.com> 09.07.04 18:10:24 >>>
"Jan Beulich" <JBeulich@novell.com> writes:

> I don't mean to have support for this on 32-bit archs (as I already
> expressed a couple of times). On 64-bit archs, gcc already has
> almost all of the required functionality, so no fundamental work is
> needed.

That's fine, but you should understand that that also makes the
project a lot less interesting.

>>2) sizeof(long) >= sizeof(any standard typedef, especially size_t).
>
> This is not, and never has been.

You seem to have missed where I said "this was an ironclad guarantee
under C90".  That's the most important sentence in my entire previous
email.  (Section 6.1.2.5.  Read the first three paragraphs very
carefully and think about their implications.  In particular, the list
in paragraph 3 is exhaustive.)

long long was introduced in spite of that guarantee, and C99
retroactively blessed it - which, as I said, is a catastrophic 
bug in C99.

> See P64 data models on 64-bit archs (as used by Windows among
> others), and also ILP32 ones (where long long then exceeds pointer
> width, since C99 requires long long to be at least 64 bits wide, and
> consequently on such a model intmax_t must also be at least 64 bits
> wide, since long long is no doubt a standard integer type).

P64 models are hopelessly broken, as they violate both criteria (1)
and (2).

ILP32,LL64 (with sizeof(intmax_t) == sizeof(long)) is just fine.  This
excludes "long long" from the set of "integer types" (as is defined in
C99), which is a perfectly sensible thing to do; by defining the ABI
that way you indicate your willingness to stick to C90's guarantee.
There is nothing wrong with supporting a type which is not an integer
type but can be used like an integer type, except that it can't be
used by the C library for any of its standard typedefs.  We are
willing to support __int128_t on that basis.

ILP32,LL64 (with sizeof(intmax_t) == sizeof(long long)) is a mistake,
and one which is unfortunately encouraged by C99.  (You're correct
that long long is a C99 standard integer type; this is another symptom
of the aforementioned catastrophic bug.)  However, it's not a major
problem, primarily because no one uses intmax_t, and secondarily
because the expectation is that ILP32 will fade away in favor of LP64
over the next decade or so.

These are *not* points on which reasonable people may disagree.  These
are basic design constraints which must be preserved lest we break
millions of lines of other people's code.  You need to understand and
accept them, and the rationale behind them, before you continue with
work in this area.

zw