[U-Boot] [PATCH] ppc4xx: Enable support for 64bit printf on all PPC4xx variants
Jerry Van Baren
gerald.vanbaren at ge.com
Thu Jul 9 14:24:49 CEST 2009
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>
More information about the U-Boot
mailing list