K
Keith Thompson
jacob navia said:
It doesn't, and nobody has ever said it did. You can do whatever you
like with your compiler and I applaud you for doing so (though I have
no use for it myself, since I don't do any win32-specific
programming).
It is your attitude and your behavior in this newsgroup that is
damaging your reputation, as well as your apparent in ability to
understand repeated explanations. Perhaps I should try explaining
this to you in words of one syllable.
Nobody has said you shouldn't implement anything you like in your
compiler.
What will it take for you to realize that *nobody has said that*?
You can, if you like, implement 128-bit integers without even using an
extension. You can make your "long long" type 128 bits; for example,
you might have:
char 8 bits
short 16 bits
int 32 bits
long 64 bits
long long 128 bits
and nobody here would have the slightest problem with it.
Or you could keep long long as 64 bits and provide one or more
"extended integer types", as described in C99 6.2.5. You could call
your 128-bit signed type something like __int128_t, and your 128-bit
unsigned type __uint128_t. No special header would be required.
Presumably int128_t and intmax_t iin <inttypes.h> would be typedefs
for __int128_t; likewise for the unsigned version. Again, this would
be entirely within the standard, and nobody here would complain (but
of course we would point out that any code that depends on the
existence of a 128-bit type is not portable to any implementation that
doesn't support it).
Or, if you prefer it for some reason, you can provide 128-bit types
using a compiler extension, and require a system-specific header for
any code that uses them. This is a perfectly valid extension, and
nobody has a problem with you implementing such a thing in your
compiler.
The *only* problem is your insistence on pushing your own exensions in
this newsgroup, and whining about the fact that they haven't been
added to the standard.
If I want 128-bit integers, I can find an existing portable library
that implements them, or I can use a library that provides arbitrary
multiple-precision types (at the expense of some loss of performance),
or (with some difficulty) I can write one myself. Using your
lcc-win32 library is not an option for me because I'm not interested
in writing code that I can run only on win32 systems.
Of course it is. Portability at *some* cost is perfectly sensible,
though.
It's true the comp.lang.c has no charter, for the simple reason that
it was created (as net.lang.c) before newsgroup charters existed.
There is a general consensus that the the topic of this newsgroup is
the C language as defined by the ISO standard(s), and that discussions
of system-specific extensions are off-topic.
If you don't like the way this newsgroup works, perhaps you should
consider posting in comp.compilers.lcc. You practically have your own
newsgroup; why on Earth do you feel the need to come here and tell us
how to run this one?
Once again, in case I still haven't gotten through to you. Nobody has
any problem with you implementing extensions in your own compiler.
Nobody says that non-portable code is evil; when it's necessary,
there's nothing wrong with it. Our only concern is the topicality of
posts to this newsgroup. Many of us find it useful to have a
newsgroup that only discusses the C language as defined by the
standard. Why do you have a problem with that?