Ted Lemon asks (shortly after having pleaded in email for it all to stop)
> > There was a right way to define the extended long type.  GNU's pomposity
> > is no excuse for their incompetance.
> ...and that is?

There are two issues here directly relevant to the problem in question, and
one of general relevance.  "long long", as I've said, is a technically flawed
extension, for reasons that have been beaten to death here and especially
on comp.std.c.  But even if the GNU folks had chosen an extension that
allowed user programs using it directly to look like valid C, there would
still be the question of how (or whether) to diagnose the case of a user
making use of the extension indirectly (e.g. by having 'typedef __long64__
off_t;" appear in an included header file).  They should have considered
how to enable developers to offer these extensions without having users
irritated by needless messages.  (I liked the suggestion of a #pragma; it
almost gives #pragma an excuse for existing :-).

More generally, the attitude of the maintainers of GNU C toward code
portability is really, really irritating.  Even beyond their belief that
conforming to standard practice is only for "pedants" is their lax attitude
toward processor independance; check out their official guide to portability,
which ought to have been subtitled "How to make your processor architecture
portable to GNU C."  If GNU had had fewer people, they might have been able
to agree on which endian-ness was "right", and GNU C would have no doubt
supported only that...

In 13 years of professional programming, I've seen too much bad code to
have any patience at all with MORE bad code.