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

[Richard Smith]

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.]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20141111/8fba8c1a/attachment.html>