[PATCH] [libc++] reject <chrono> literals that can't be represented

[Hal Finkel]

----- Original Message -----
> From: "Richard Smith" <richard at metafoo.co.uk>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Marshall Clow" <mclow.lists at gmail.com>, "Eric Fiselier" <eric at efcs.ca>, "cfe commits" <cfe-commits at cs.uiuc.edu>
> Sent: Tuesday, November 11, 2014 2:48:00 PM
> Subject: Re: [PATCH] [libc++] reject <chrono> literals that can't be represented
> 
> 
> 
> 
> On Tue, Nov 11, 2014 at 12:41 PM, Hal Finkel < hfinkel at anl.gov >
> wrote:
> 
> 
> ----- Original Message -----
> > From: "Richard Smith" < richard at metafoo.co.uk >
> > To: "Marshall Clow" < mclow.lists at gmail.com >, "Eric Fiselier" <
> > eric at efcs.ca >, "cfe commits" < cfe-commits at cs.uiuc.edu >
> > Sent: Tuesday, November 11, 2014 2:05:21 PM
> > Subject: [PATCH] [libc++] reject <chrono> literals that can't be
> > represented
> > 
> > 
> > 
> > [time.duration.literals]p3 says:
> > 
> > 
> > "If any of these suffixes are applied to an integer literal and the
> > resulting chrono::duration value cannot be represented in the
> > result
> > type because of overflow, the program is ill-formed."
> > 
> > 
> > That's unimplementable in standard C++, but implementable with
> > Clang
> > using the enable_if attribute. This patch also rejects
> > 
> > 
> > (void) operator""ns(0x8000000000000000ull);
> > 
> > 
> > ... and it's not entirely clear whether that's permissible, but
> > this
> > is the best we can do at the moment (and I think it's a good thing
> > to reject the above code).
> > 
> > 
> > Thoughts?
> 
> Are there other places in <chrono> that require a language extension?
> Requiring a language extension to implement <chrono> seems like a
> bug in the specification. I'd vote for an LWG issue.
> 
> There already is one:
> http://cplusplus.github.io/LWG/lwg-active.html#2383 -- my preferred
> fix for that is to simply make it "no diagnostic required", so that
> we can continue to diagnose this and other implementations can do
> something worse =) [... and then, eventually, to improve the core
> language such that this doesn't require an extension, and remove the
> "no diagnostic required" again.]

Sounds good. I don't really have an opinion on whether we jump the resolution of this issue or not. We might not, however, want to introduce a semi-permanent disparity between the behavior of libc++ compiled with Clang and libc++ compiled with other compilers (by using a Clang-specific extension here). I mention this not because I care, but just in case others might.

 -Hal

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory