public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "david dot asher at cavium dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/11352] New: crash while internal padding numeric 0 Date: Fri, 27 Jun 2003 13:48:00 -0000 [thread overview] Message-ID: <20030627134827.11352.david.asher@cavium.com> (raw) PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11352 Summary: crash while internal padding numeric 0 Product: gcc Version: 3.2.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: david dot asher at cavium dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux GCC host triplet: i686-pc-linux GCC target triplet: i686-pc-linux When padding a numeric 0 in _S_pad, the code in locale_facets.tcc checks to see if the old string starts with a "0x". Unfortunately, the code which produces the unpadded string DOES NOT zero terminate: the code is relying upon passing the length around with the string Later, the code in _S_pad which determines whether the leading "0X" or "0x" is present DOES NOT check whether the "x" is beyond the end of the string. In my case I was outputting a 0 AFTER a non-zero value w/showbase on, so the __olds string had a "x" lying around on the stack -- fooling the code into thinking it needs to place the pad after a non-existant "0x". Because of the inconsistancies in the length fields after this decision it caused the final copy to use a length of -1. In my case it was internal padding a 0 to a width of 5. __oldlen=1, __newlen=5. Therefore __plen=4. __testhex is incorrectly evaluated to true because an "x" just happens to be at __olds[1] -- even though __oldlen=1. This causes: __mod = 2 __beglen = __plen = 4 __newlen = 5 So the end copy length is calculated: 5 - 4 - 2 = -1 !! Horrible death ensues. The following patch fixes the problem (I checked out the gcc/libstdc++-v3 sources 27-Jun-2003 9pm-ish EDT to create the patch, hopefully linewrap won't screw this up too bad): *** locale_facets.tcc.old Tue May 27 17:14:49 2003 --- locale_facets.tcc Thu Jun 26 20:48:07 2003 *************** namespace std *** 2188,2195 **** || _Traits::eq(__olds[0], __plus); bool __testhex = _Traits::eq(__ctype.widen('0'), __olds[0]) ! && (_Traits::eq(__ctype.widen('x'), __olds[1]) ! || _Traits::eq(__ctype.widen('X'), __olds[1])); if (__testhex) { __news[0] = __olds[0]; --- 2188,2195 ---- || _Traits::eq(__olds[0], __plus); bool __testhex = _Traits::eq(__ctype.widen('0'), __olds[0]) ! && ((__oldlen > 1) && (_Traits::eq(__ctype.widen ('x'), __olds[1]) ! || _Traits::eq(__ctype.widen ('X'), __olds[1]))); if (__testhex) { __news[0] = __olds[0];
next reply other threads:[~2003-06-27 13:48 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-06-27 13:48 david dot asher at cavium dot com [this message] 2003-06-27 13:50 ` [Bug libstdc++/11352] " david dot asher at cavium dot com 2003-06-27 21:49 ` paolo at gcc dot gnu dot org 2003-07-20 20:48 ` pinskia at physics dot uc dot edu 2003-08-03 19:00 ` neroden at gcc dot gnu dot org 2003-12-19 9:57 ` pinskia at gcc dot gnu dot org 2003-12-19 10:01 ` paolo at gcc dot gnu dot org 2004-01-14 3:17 ` pinskia at gcc dot gnu dot org 2004-02-14 4:02 ` ian at wasabisystems dot com 2004-02-14 8:03 ` pcarlini at suse dot de 2004-02-15 17:19 ` cvs-commit at gcc dot gnu dot org 2004-02-15 17:33 ` cvs-commit at gcc dot gnu dot org 2004-02-15 17:34 ` pcarlini at suse dot de 2004-05-26 13:58 ` cvs-commit at gcc dot gnu dot org 2004-06-28 20:21 ` cvs-commit at gcc dot gnu dot org 2004-06-28 20:23 ` pinskia at gcc dot gnu dot org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20030627134827.11352.david.asher@cavium.com \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).