From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Thu, 09 Jul 2009 08:24:49 -0400 Subject: [U-Boot] [PATCH] ppc4xx: Enable support for 64bit printf on all PPC4xx variants In-Reply-To: <200907090700.19816.sr@denx.de> References: <1246873688-25113-1-git-send-email-sr@denx.de> <4A550B66.1090506@freescale.com> <4A551B4E.6010102@gmail.com> <200907090700.19816.sr@denx.de> Message-ID: <4A55E191.9090402@ge.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Stefan Roese wrote: > On Thursday 09 July 2009 00:18:54 Jerry Van Baren wrote: >> Regardless of the in/out debate, we should print a warning if %ll is >> used but not supported. I would suggest simply printing the "%lld" (or >> whatever the format is) and pop two longs from the varargs. That would >> make it clear something is missing and probably wrong. >> >> I don't like printing half and discarding half: it will be erroneous >> with no warning if the upper half != 0. It would also have endian >> complications since the half you want to discard depends on the >> machine's endianness (not insurmountable). >> >> One possible enhancement is to special-case %ll[0-9]*[Xx] and treat it >> as as two %08lx formats. Hmmm, this would need correct endian handling >> too. :-/ > > All this would increase the code size for those boards not supporting the > 64bit printf format. Not sure by how much, but I suggest to just fix the > problem by supporting this format correctly instead of adding new code to > print some warnings here. > > Best regards, > Stefan That is what Scott is trying to do, but fixing 64bit printf causes a 2K++ increase in size to the boards that don't currently support 64bit printf (some of which are broken due to the error). Wolfgang is resisting that. Adding code to print a warning and handle the varargs properly will probably be less than 100 bytes. It looks like this is the compromise Wolfgang favors. On a related note, I am *strongly* opposed to popping a long long and only printing half of it. While odds are good that it will be correct, when the upper half is non-zero, it will be silently printing a totally erroneous value. FWIIW, in the avionics business, silently displaying an erroneous value is the unpardonable sin. It is better to sometimes not display correct data and never display incorrect data than it is to rarely (as in 1e-9 .. 1e-12) display incorrect data. Hundreds of people have died because of this.[1] Best regards, gvb [1] Just a couple examples: (unknown cause, but incorrect airspeed indication is a known contributing factor)