lins@Apple.COM (Chuck Lins) (09/28/89)
It has been reported to me by someone in Japan regarding a type transfer/
conversion problem with the Logitech Modula-2 compiler (sorry I don't know
which version). Here's the problem:
There's a module exporting an opaque type, Item, which is defined as a 4-byte
address in the implementation. E.G.,
DEFINITION MODULE Items;
TYPE Item;
END Items.
IMPLEMENTATION MODULE Items;
TYPE Item = ADDRESS; (* assume the necessary IMPORTs *)
END Items.
Item is treated as a generic 4-byte quantity by other modules of a library of
data structures. For example, in a Stack module one my want a stack of CHARs,
and assuming the proper instaniation of a stack, etc. you could write:
StackModule.Push(toMyStack, Item(someCharacterVariable));
The specific example I have is summarized as:
IMPLEMENTATION MODULE ItemOperations;
...
PROCEDURE CharCompare (left:Item; right:Item): Relation;
VAR leftChar : CHAR;
rightChar: CHAR;
BEGIN
leftChar := CHAR(left); (* error: 'uncompatible types in conversion' *)
rightChar:= CHAR(right); (* same error *)
... blah, blah using the characters
END CharCompare;
...
END ItemOperations.
This all compiles fine under JPI's TopSpeed Modula-2. I suspect that this
compiles ok under the Stony Brook compiler (I don't have any reports to the
contrary). The same error is apparently reported on other type conversions as
well (e.g., to an INTEGER).
BTW, this is all part of the "Modula-2 Software Component Library" - so if
there's anyone out there using the library with the Logitech compiler please
let me know if there's a problem here. Or if you're using the library on
_any_ other compiler and have had problems definitely let me know.
Thanks in advance.
Chuck Lins
--
Chuck Lins | "Exit left to funway."
Apple Computer, Inc. | Internet: lins@apple.com
20525 Mariani Avenue | AppleLink: LINS
Mail Stop 41-K |
Cupertino, CA 95014 | "Self-proclaimed Object Oberon Evangelist"
I speak for myself and no one else.randy@m2xenix.UUCP (Randy Bush) (09/30/89)
In article <35093@apple.Apple.COM> lins@Apple.COM (Chuck Lins) writes: > DEFINITION MODULE Items; > TYPE Item; > END Items. > ... > PROCEDURE CharCompare (left:Item; right:Item): Relation; > VAR leftChar : CHAR; > BEGIN > leftChar := CHAR(left); (* error: 'uncompatible types in conversion' *) But, the type transfer CHAR(left) requires that left occupy the same number of bits as a CHAR, and this would not seem to be the case here, where left would seem to be a pointer. Also, the importing module would seem to be trying to peek through the opaque if it tried something like CHAR(left^). >This all compiles fine under JPI's TopSpeed Modula-2. This may not be to their credit. -- uunet!tektronix ----\ sun!nosun --------- qiclab ---- m2xenix!randy or randy@m2xenix.uucp uunet!oresoft ------------------/
Barry.Cornelius@DURHAM.AC.UK (10/02/89)
Last Saturday, my colleague Randy Bush wrote to this newsgroup thus:
*In article <35093@apple.Apple.COM> lins@Apple.COM (Chuck Lins) writes:
*> DEFINITION MODULE Items;
*> TYPE Item;
*> END Items.
*> ...
*> PROCEDURE CharCompare (left:Item; right:Item): Relation;
*> VAR leftChar : CHAR;
*> BEGIN
*
*But, the type transfer CHAR(left) requires that left occupy the same number of
*bits as a CHAR, and this would not seem to be the case here, where left would
*seem to be a pointer.
*Also, the importing module would seem to be trying to peek through the opaque
*if it tried something like CHAR(left).
*>This all compiles fine under JPI's TopSpeed Modula-2.
*This may not be to their credit.
I guess strictly speaking PIM does not say that 'left' needs to occupy the
same number of bits as CHAR. However, this has been the case with some
implementations, whereas others allow more flexibility. This is the case
with JPI TopSpeed Modula-2, where the size of the expression may be
less-than/equal-to/greater-than the size of the result-type of the type
transfer. With TopSpeed Modula-2 a pointer occupies 4 bytes and so the
type transfer (aka a cast) "CHAR(left)" would deliver one of the bytes of
these four.
My guess is that TopSpeed Modula-2 would not allow "CHAR(left)" to appear
in an importing module, but I have not checked this.
==
Barry Cornelius
==
Computer Science Group, School of Engineering and Applied Science,
University of Durham, Durham, DH1 3LE, England
JANET: Barry.Cornelius@uk.ac.durham
Internet: Barry.Cornelius%durham.ac.uk@cunyvm.cuny.edu
UUCP: ...ukc!cs.nott.ac.uk!bjc
BITNET/EARN: Barry.Cornelius%DURHAM@AC.UK
Tel: Durham (091 or +44 91) 374 2638, Secretary: 374 2630, Fax: 374 3741