On (19 Aug 97) Neil Heller wrote to Chris Downs...
 NH> Today I saw an interesting expression like I had never seen before.
 NH> In a call to SendMessage, the variable that's sent as the LPARAM is (I
 NH> guess) supposed to be a long.  The original programmer wanted to send
 NH> a FAR pointer to a CSTRING (while compiling the whole shebang in the
 NH> medium modle) so what he did was a double cast (or at least that's
 NH> what I took it to be):
 NH> (long)(LPSTR)foovar...
 NH> We are now compiling everything in the large modle so I was advised to
 NH> change the above to:
 NH> (LPARAM)foovar...
 NH> My question is this:  was I correct in assuming that the first example
 NH> above is a double cast?  If so, are double casts common elsewhere?
Yes, it's a double cast.  They used to be fairly common in Windows, but
are fairly uncommon elsewhere.
 NH> In any case wouldn't the LPSTR cast have done the trick or is the
 NH> second cast to long necessary to change the segment:offset notation
 NH> for the 16-bit environment to something a bit more flat?
The situation at the time was that you needed to pass a long, and you
were starting with a 16 bit pointer.  The 16 bit pointer consisted of
only an offset, with the segment being iplicitly the process's data
segment.
If you convert directly from a near pointer to a long, it basically just
zero fills the upper 16 bits of the long.
However, if you convert the near pointer to a far pointer, it fills the
upper 16 bits with the segment for that pointer (i.e. the current
process' data segment).  Converting that to a long then allows you to
pass the pointer as a long.
Ultimately, this is a problem primarily in the design of Windows itself.
Rather than passing pointers as pointers, it passes pointers as integers
which keeps the compiler from being able to maintain sanity and/or type
checking.
    Later,
    Jerry.
... The Universe is a figment of its own imagination.
--- PPoint 1.90
---------------