From owner-freebsd-current Tue Jan 20 13:23:53 1998 Return-Path: Received: (from daemon@localhost) by hub.freebsd.org (8.8.8/8.8.8) id NAA06795 for current-outgoing; Tue, 20 Jan 1998 13:23:53 -0800 (PST) (envelope-from owner-freebsd-current) Received: from kithrup.com (kithrup.com [205.179.156.40]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id NAA06766 for ; Tue, 20 Jan 1998 13:23:37 -0800 (PST) (envelope-from sef@kithrup.com) Received: (from sef@localhost) by kithrup.com (8.8.8/8.8.7) id NAA15093; Tue, 20 Jan 1998 13:23:31 -0800 (PST) (envelope-from sef) Date: Tue, 20 Jan 1998 13:23:31 -0800 (PST) From: Sean Eric Fagan Message-Id: <199801202123.NAA15093@kithrup.com> To: current@freebsd.org Subject: Re: Nasty GCC bug? In-Reply-To: <199801202053.NAA25835.kithrup.freebsd.current@usr06.primenet.com> References: from "=?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?=" at Jan 20, 98 10:47:03 pm Organization: Kithrup Enterprises, Ltd. Sender: owner-freebsd-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In article <199801202053.NAA25835.kithrup.freebsd.current@usr06.primenet.com> you write: I don't normally do this, but: Terry you don't know what you're talking about. As I've explained in my two messages today. >%x expects and int, %lx expects a long. There is not one that expects >a short or a char. %x expects an unsigned int, and takes the normal modifiers. 'l', 'q', and 'h' specify sizes -- long, quad, and short, respectively. The 'h' size modifier has only been around for about 20 years now, so maybe I shouldn't expect you to know about it. >Also, my field width limits are being ignored. I kind of expected >it to print out a field limit's worth of hex characters, starting at >the lsb. What his this "lsb" you keep talking about? printf doesn't know anything about bytes; all it knows abotu are values, and characters. Your field width limits were not being ignored, as, if you read the man page (which I quoted you in my previous message), you'd see that it's the *minimum field width*, not the maximum. >The problem initially showed in a program that sscanf'ed into an >int of %2x, assigned a character array valued to the int, and then >tried to printf the char value to get back out what it scanned in. It's not my fault the program in question was buggy -- it has always been the case that you had to mask out signed char values for printf statements, since printf has never had a size modifier to treat a char-sized value as an integer.