This is the mail archive of the
mailing list for the GCC project.
Re: Warnings on long constants in gcc 3.3, 3.4
On Tue, 13 Jul 2004, Jack Lloyd wrote:
> I was only going to bring this up when I had time to finish my patch (changing
> one line of code in GCC seems to involve a lot of work <g>), but this solution
> doesn't work for C++. One could easily argue that as the long long type doesn't
> exist in C++ right now, it's not valid, but given that it historically (<3.3)
> the usage of the OP has been usable in C++ as well, that seems bad. In
> particlar, as the OP mentioned, a lot of Windows compilers don't like LL, but
> have no problem with a 64-bit constant that has no suffix at all.
> My proposed fix was to have -Wno-long-long disable this warning (actually an
> error in C++), which will work for both C and C++. It's on by default
> (regardless of the settings of -Wall/-Wextra), so random users who added an
> extra hex digit onto their int constant (or whatever) would not be affected.
> Some discussion on this is in PR/13358.
-Wno-long-long seems to make sense for this case.
The more general issue is that we "support" (incomplete approximations to)
several C and C++ standards - albeit without the resources to spend on
conformance to make the implementations completely conforming to any of
the standards. Then we support GNU extended versions of them. Then we
support Objective-C. Then we have options to allow extra features, or
disable diagnostics for them (such as -Wno-long-long). Then people want
to use or add support for standards that build on top of those underlying
standards, such as OpenMP which can build on any of C90, C99 and C++98.
Then people want to use features from one language or standard on top of
another - whether using long long from C99 on top of C++, as here, or
Objective-C features in C++ (which seems to be something of what
Objective-C++ is about), or other combinations. And all these
combinations of features are liable to have complicated interactions,
leading to a maintainability mess (when even getting towards support for
the underlying standards is hard enough). There have been many criticisms
of GCC for having too many options; those relating to language dialects
are generally more problematic than others. In *this case* long long is
fairly unproblematic as a feature in C++, but in general the question of
whether we want a new language dialect option (potentially doubling the
number of dialects involved) always needs very careful consideration.
Joseph S. Myers http://www.srcf.ucam.org/~jsm28/gcc/
firstname.lastname@example.org (personal mail)
email@example.com (Bugzilla assignments and CCs)