Path: utzoo!attcan!uunet!ncrlnk!ncrcae!hubcap!gatech!bloom-beacon!ATHENA.MIT.EDU!swick
From: swick@ATHENA.MIT.EDU (Ralph R. Swick)
Newsgroups: comp.windows.x
Subject: Re: Bug in Athena scrollbar widget (float resource)
Message-ID: <8812191707.AA15220@LYRE.MIT.EDU>
Date: 19 Dec 88 17:07:17 GMT
References: <8812191103.AA16776@tub.UUCP>
Sender: daemon@bloom-beacon.MIT.EDU
Organization: DEC/MIT Project Athena
Lines: 31

> If I am assumed to store a pointer to a float into an
> XtArgVal, then the type for XtRFloat is `float*', not `float'.

The XtR representation name corresponding to a particular data
format is not necessarily a function of the number of bytes in
the storage representation.  There is certainly no architectual
requirement to this effect.  The XtR name is merely a tag to
allow portable software to match data types; the correspondence
between the tag and the storage representation is defined by a
table, not by an algorithm.  'Intrinsics' defines the tag for
C-type 'float' to be 'XtRFloat'.  If a widget wants to define
a resource of type 'float*', it will need to declare a new
representation tag (e.g. XtRFloatPointer).

> show me how the `float' resources can be set
> by means of XtSetValues.

As you pointed out earlier, portable software cannot assume a priori
that XtArgVals are big enough to hold a float and must therefore test
before deciding whether an individual entry in an arglist is by-value
or by-reference.  This is machine dependent, but the rule is simple
and the answer is known at compile time.  This is true for _any_
data type not in the list given in the first paragraph of section 2.4.1
of 'Intrinsics'.

Given the propensity of C to do type conversions, it may be necessary
in some cases to defeat this automatic 'feature' of the language.
This is true of the X11R3 implementation of Intrinsic.h, so if
sizeof(float) <= sizeof(XtArgVal) in your implementation, you'll have
to use something equivalent to bcopy() to move the bytes rather than a
direct assignment.