Xref: utzoo unix-pc.general:7236 comp.sys.att:11488 Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!tut.cis.ohio-state.edu!magnus.ircc.ohio-state.edu!zaphod.mps.ohio-state.edu!rpi!julius.cs.uiuc.edu!apple!portal!cup.portal.com!thad From: thad@cup.portal.com (Thad P Floryan) Newsgroups: unix-pc.general,comp.sys.att Subject: Re: 3B1 C runtime library bug; do you have it too? Message-ID: <37980@cup.portal.com> Date: 13 Jan 91 13:22:56 GMT References: <37567@cup.portal.com> <902@jonlab.UUCP> <1471@das13.snide.com> Organization: The Portal System (TM) Lines: 48 Nothing like more fuel on the fire, eh? Just when you thought you could resign yourself to never getting leading zeroes in your printf() output, the 3B1's standard libraries are a bit inconsistent, producing: 1 0000001 123456 0123456 1 0000001 7654321 7654321 1 0000001 162534 0162534 1.234 1.234 12345.789 12345.789 with the following simple test program. It now seems there are in fact two bugs with "f" formats: one where the format is NOT processed at all if there's a leading zero spec before dynamic field sizing (my original report), and one where it simply doesn't "do" the leading zero for a more-copacetic format per: #include char *decfmt = "%7d %07d\n"; char *octfmt = "%7o %07o\n"; char *hexfmt = "%7x %07x\n"; char *fltfmt = "%10.3f %010.3f\n"; #define d1 1 #define d2 123456 #define o1 1 #define o2 07654321 #define h1 1 #define h2 0x162534 #define f1 1.234 #define f2 12345.789 main() { printf(decfmt, d1, d1); printf(decfmt, d2, d2); printf(octfmt, o1, o1); printf(octfmt, o2, o2); printf(hexfmt, h1, h1); printf(hexfmt, h2, h2); printf(fltfmt, f1, f1); printf(fltfmt, f2, f2); } Time allowing, I'll be checking-out the BSD format cracker and printer. Thad Floryan [ thad@cup.portal.com ]