On Tue, Dec 11, 2001 at 10:10:38PM -0600, Ben Combee wrote:
> "Michael Glickman" <[EMAIL PROTECTED]> wrote:
>> GCC would give a warning in this case (when used with -Wall), will CW ?
No, it won't. You might like to test your pronouncements before you
make them. It'd only take a minute, and would save us all some time.
> The third parameter to DmWrite is a "const void *". Since a MemHandle
> is defined as a "struct _opaque *" by the PalmTypes.h header, it
> converts silently
[...]
> I don't think there is a way to get CodeWarrior to warn about this,
> since it is valid C.
Right. Keith shouldn't have been amazed not to get warned about this. :-)
> In a sense, it would be a lot better if MemHandle
> was defined as a 4-byte struct, since that can't silently convert to
> anything -- however, a struct like that wouldn't be able to be stored in
> a register as a temporary by the compiler due to the more complicated
> type.
A *good* compiler is perfectly capable of storing small structs in
registers. :-)
When the 3.5 SDK was in development, we tried to define MemHandle as
something that *really* wouldn't convert to MemPtr, and something like
what you're suggesting was considered. Ken Krugler identified the real
reason why this couldn't be done: MemHandle will always have to be a
pointer of some kind, or otherwise binary compatibility will be broken
for system functions which return MemHandles.
> (C++ disallows the other way).
Making it a "struct _OpaqueMemHandleContents *" was the best anyone
could think of. As you say, this enables a warning in C++ and IIRC
it enables warnings in both C and C++ in various other situations
involving MemPtr/MemHandle confusion.
Remember: when you can immediately think of something about the SDK
that "would be a lot better if", the chances are that the SDK writers
thought of it too. :-) There's often a good reason for the way things
are done.
John
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
