[Bug c++/52654] [C++11] Warn on overflow in user-defined literals

[manu at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52654

--- Comment #17 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2012-04-06 18:38:51 UTC ---
(In reply to comment #16)
> Thank you for your comments.
> 
> I was trying to follow the style of enum that I saw in the vicinity of the code
> I was editing.  I was not able to discern a single style.  If lower-case is
> more modern (I like it) then that's good for me.  I have no problem moving it

Actually, I don't know what is the best style, I just looked at the other enum
defined in real.h

> to real.h and using it all over either (I think just one return type).  I also
> used the enum in interpret_integer though.  Maybe that's not a problem really.
> 
> Maybe I could go as far as changing cpp_number.overflow to use this enum as
> well instead of a bool? - no real is not part of libcpp by design it seems.

Well, libcpp seems not to care about the difference between underflow and
overflow, so why bother to modify it? Also real and libcpp are independent, so
this seems to me adding a dependence that is not needed.

> As far as just storing a string and parsing it later you may be right.  Up to
> now it was just convenient to keep the numeric values.  I tried to figure out
> how to run interpret_integer, etc in parser but I got stuck trying to feed
> cpp_token in parser in the c++ fe when all I could see was cp_token.  Is there
> a way I can get the preprocessor token from the C++ token or is the former
> stored somewhere?  If so I'll do that in a heartbeat.  OK, I'll try
> parse_in->cut_token.

Oh, I see the problem now. So I guess that what you did is the most
straightforward way then. Unless someone more knowledgeable proposes a nice way
to avoid passing this info around.

> I thought about breaking up interpret_ into separate pieces that took strings
> but that seemed like more trouble than it was worth.

Indeed. I see your point. It would be nice to be able to call these functions
from the C++ FE to avoid passing all this info around, and also avoid
interpreting the numbers if they are not actually numbers, and avoid checking
for user-def literals in CPP. 

Is parse_in still valid at the moment that cp_parser_userdef_ functions are
called? In fact, cpp_interpret_integer only needs a valid cpp_reader, it
doesn't use its token argument for anything but the string.

Again, I am not maintainer, so it would be nice if some maintainer expressed
their opinion.