[U-Boot] [PATCH] ppc4xx: Enable support for 64bit printf on all PPC4xx variants

[Jerry Van Baren <gerald.vanbaren@ge.com>]

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.
   <http://en.wikipedia.org/wiki/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:
<http://online.wsj.com/article/SB124411224440184797.html> (unknown 
cause, but incorrect airspeed indication is a known contributing factor)
<http://www.computerweekly.com/blogs/tony_collins/2009/06/youre-flying-too-fast-and-too.html>
<http://www.computerweekly.com/Articles/2009/06/12/236425/crash-one-birgenair-flight-301.htm>
<http://www.computerweekly.com/Articles/2009/06/12/236431/crash-two-aeroper-flight-603.htm>