From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30945 invoked by alias); 6 Apr 2012 18:39:12 -0000 Received: (qmail 30923 invoked by uid 22791); 6 Apr 2012 18:39:10 -0000 X-SWARE-Spam-Status: No, hits=-4.2 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 06 Apr 2012 18:38:55 +0000 From: "manu at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/52654] [C++11] Warn on overflow in user-defined literals Date: Fri, 06 Apr 2012 18:39:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: manu at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-04/txt/msg00443.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D52654 --- Comment #17 from Manuel L=C3=B3pez-Ib=C3=A1=C3=B1ez 2012-04-06 18:38:51 UTC --- (In reply to comment #16) > Thank you for your comments. >=20 > I was trying to follow the style of enum that I saw in the vicinity of th= e 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 movin= g it Actually, I don't know what is the best style, I just looked at the other e= num 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 re= ally. >=20 > 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 seem= s. 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. U= p 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 str= ings > 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 functio= ns 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 checki= ng for user-def literals in CPP.=20 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.