Dear ROOTers,
I'm having some problems with passing Short_t variables to Form() when
using CINT. When I use in a macro something like
cout << Form("enum: %5d; q[2] = %8.8x %8.8x",
i_nevent, on_camac->q[2], (Int_t) on_camac->q[2])
<< endl;
with i_nevent being an Int_t and q[] being an array of Short_t I get
sometimes confused output for the 2nd argument which is passed as
Short_t. A sample output might look like
enum: 0; q[2] = 000000aa 000000aa
enum: 1; q[2] = 08ac012e 0000012e
enum: 2; q[2] = 08ac00fb 000000fb
enum: 3; q[2] = 08ac0129 00000129
enum: 4; q[2] = 08ac00f2 000000f2
When running this as compiled code (via ACLiC) I get
enum: 0; q[2] = 000000aa 000000aa
enum: 1; q[2] = 0000012e 0000012e
enum: 2; q[2] = 000000fb 000000fb
enum: 3; q[2] = 00000129 00000129
enum: 4; q[2] = 000000f2 000000f2
My understanding of variable argument lists (as used in Form()) is
that char and short types are promoted to int before they are passed,
also floats are promoted to double, like in traditional C.
So I'm led to the assumption that CINT does not always properly properly
do this for Short_t variables. As a consequence a %d or %x conversion,
which accesses an int, sees sometimes garbage in the upper 16 bits.
It seems that these problems occur only for the 2nd or later parameters
of the ellipse (that is the 3rd one or later in the total arglist).
With best regards,
Walter
--
--
Walter F.J. Mueller Mail: W.F.J.Mueller@gsi.de
GSI, Abteilung KP3 Phone: +49-6159-71-2766
D-64291 Darmstadt FAX: +49-6159-71-2989
WWW: http://www-kp3.gsi.de/www/kp3/people/mueller.html
This archive was generated by hypermail 2b29 : Thu Jan 01 2004 - 17:50:14 MET