From owner-cvs-src@FreeBSD.ORG Tue Dec 13 13:23:39 2005 Return-Path: X-Original-To: cvs-src@FreeBSD.org Delivered-To: cvs-src@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B16B516A420; Tue, 13 Dec 2005 13:23:39 +0000 (GMT) (envelope-from phk@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8090343D83; Tue, 13 Dec 2005 13:23:29 +0000 (GMT) (envelope-from phk@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.13.1/8.13.1) with ESMTP id jBDDNR2v052089; Tue, 13 Dec 2005 13:23:27 GMT (envelope-from phk@repoman.freebsd.org) Received: (from phk@localhost) by repoman.freebsd.org (8.13.1/8.13.1/Submit) id jBDDNR2W052088; Tue, 13 Dec 2005 13:23:27 GMT (envelope-from phk) Message-Id: <200512131323.jBDDNR2W052088@repoman.freebsd.org> From: Poul-Henning Kamp Date: Tue, 13 Dec 2005 13:23:27 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org X-FreeBSD-CVS-Branch: HEAD Cc: Subject: cvs commit: src/lib/libc/stdio vfprintf.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2005 13:23:39 -0000 phk 2005-12-13 13:23:27 UTC FreeBSD src repository Modified files: lib/libc/stdio vfprintf.c Log: /* You're not supposed to hit this problem */ For some denormalized long double values, a bug in __hldtoa() (called from *printf()'s %A format) results in a base 16 digit being rounded up from 0xf to 0x10. When this digit is subsequently converted to string format, an index of 10 reaches past the end of the uppper-case hex/char array, picking up whatever the code segment happen to contain at that address. This mostly seem to be some character from the upper half of the byte range. When using the %a format instead of %A, the first character past the end of the lowercase hex/char table happens to be index 0 in the uppercase hex/char table hextable and therefore the string representation features a '0', which is supposedly correct. This leads me to belive that the proper fix _may_ be as simple as masking all but the lower four bits off after incrementing a hex-digit in libc/gdtoa/_hdtoa.c:roundup(). I worry however that the upper bit in 0x10 indicates a carry not carried. Until das@ or bde@ finds time to visit this issue, extend the hexdigit arrays with a 17th index containing '?' so that we get a invalid but consistent and printable output in both %a and %A formats whenever this bug strikes. This unmasks the bug in the %a format therefore solving the real issue may both become easier and more urgent. Possibly related to: PR 85080 With help by: bde@ Revision Changes Path 1.71 +2 -2 src/lib/libc/stdio/vfprintf.c