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

[Hal Finkel]

----- 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.

 -Hal

> 
> 
> (We could do the same thing for floating-point <chrono> literals, but
> the standard doesn't allow us to do so.)
> _______________________________________________
> cfe-commits mailing list
> cfe-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
> 

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