On Tue, Nov 11, 2014 at 12:41 PM, Hal Finkel <[email protected]> wrote:
> ----- Original Message ----- > > From: "Richard Smith" <[email protected]> > > To: "Marshall Clow" <[email protected]>, "Eric Fiselier" < > [email protected]>, "cfe commits" <[email protected]> > > 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.]
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
