This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Proposal for the 'long long' problems


After much grepping, methinks that all of the uses of _GLIBCPP_USE_LONG_LONG
guarding fall into three categories:

 1)  I/O
     This includes the various put, get, do_* functions.  They depend on
     C99 functions like strtoll and strtoull.

 2)  Math
     Specializations for numeric_limits, additional functions like div/lldiv
     and abs/llabs, additional lldiv_t declaration if needed.

 3)  <witty name goes here>
     General support in the form of additional specializations for
     _Is_integer, __is_integer, type_traits, and concept checking.  No
     telling who/what are using these, so if 'long long' is on, these should
     be present.

I propose:

a)  Because the default is now to enable them, the help text for
    GLIBCPP_ENABLE_LONG_LONG should be changed to say that --disable-long-long
    is that one that needs to be explicitly used, not --enable.  A 1-line diff.

b)  Same for GLIBCPP_ENABLE_C99.

c)  The ac_c99_* variables be more granular.  For example, if lldiv_t is not
    available, we turn off ac_c99_stdlib, which may have been turned on by the
    presence of strtoll & company.  Granted that the {presence,absence} of one
    probably indicates that of the other, we can't tell from the result.

d)  Instead of one preproc symbol, we define three:
    _GLIBCPP_USE_LONG_LONG_IO     if strtoll, etc, are present; predicate
                                  this on (the reworked) ac_c99_stdlib and
                                  maybe ac_c99_wchar
    _GLIBCPP_USE_LONG_LONG_MATH   if lldiv_t and such are present; predicate
                                  on ac_c99_math (including lldiv_t)
    _GLIBCPP_USE_LONG_LONG_ANY    if any 'long long' support is possible
                                  anywhere at all

Finally,

e)  We replace the generic USE_LONG_LONG by the more specific guards:  case
    (1) with _IO, (2) with _MATH, and (3) with _ANY.

Actually, I would argue that the constructs currently guarded in (3) should
not be guarded at all.  They only depend on the compiler understanding a
type 'long long'.  They don't need any of the C99 features being examined.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]