Re: [Oberon] OBNC Sets incorrect output
Joe Most probably the compiler itself is not compiled with --c-int-type=long. The difference between the first and the second are the set constants. To check my assumption try:
MODULE testsets; IMPORT Out; VAR i : INTEGER; x,y,z : SET; BEGIN x := {}; INCL(x, 31); INCL(x, 32); INCL(x, 33); y := {}; INCL(y, 33); INCL(y, 34); INCL(y, 35}; z := x - y; FOR i := 31 TO 35 DO IF i IN z THEN Out.Int(i,4) END END; Out.Ln END testsets.
If this solved the output and you have access to the source, you could try to re-compile the compiler with the long flag turned on. br Jörg
Jorg, Thanks for the suggestion. Unfortunately the output isn't as expected; only 31 was printed. I'll contact the author about the issue. cheers, Joe March 20, 2022 6:35:33 PM CET Joerg <joerg.straube@iaeth.ch> wrote: Joe Most probably the compiler itself is not compiled with --c-int-type=long. The difference between the first and the second are the set constants. To check my assumption try: MODULE testsets; IMPORT Out; VAR i : INTEGER; x,y,z : SET; BEGIN x := {}; INCL(x, 31); INCL(x, 32); INCL(x, 33); y := {}; INCL(y, 33); INCL(y, 34); INCL(y, 35}; z := x - y; FOR i := 31 TO 35 DO IF i IN z THEN Out.Int(i,4) END END; Out.Ln END testsets. If this solved the output and you have access to the source, you could try to re-compile the compiler with the long flag turned on. br Jörg -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon -- Sent with https://mailfence.com Secure and private email
{32} will be translated to (0x1u << 32) I‘m not a C specialist, but shouldn‘t it read (0x1ull << 32) br Jörg
Am 20.03.2022 um 19:02 schrieb Joe Turner <medianjoe@mailfence.com>:
Jorg,
Thanks for the suggestion. Unfortunately the output isn't as expected; only 31 was printed. I'll contact the author about the issue. cheers, Joe
March 20, 2022 6:35:33 PM CET Joerg <joerg.straube@iaeth.ch> wrote:
Joe
Most probably the compiler itself is not compiled with --c-int-type=long. The difference between the first and the second are the set constants.
To check my assumption try:
MODULE testsets; IMPORT Out; VAR i : INTEGER; x,y,z : SET; BEGIN x := {}; INCL(x, 31); INCL(x, 32); INCL(x, 33); y := {}; INCL(y, 33); INCL(y, 34); INCL(y, 35}; z := x - y; FOR i := 31 TO 35 DO IF i IN z THEN Out.Int(i,4) END END; Out.Ln END testsets.
If this solved the output and you have access to the source, you could try to re-compile the compiler with the long flag turned on.
br Jörg
-- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
-- Sent with https://mailfence.com Secure and private email -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
Joerg writes:
{32} will be translated to (0x1u << 32)
I‘m not a C specialist, but shouldn‘t it read (0x1ull << 32)
It varies from compiler to compiler. With gcc, this will facilitate shifting more than 31 bits. But, shifting more than the number of bits in an integer is entering into 'undefined behavior' (or is it 'implementation defined') territory. -- I have never met a beet which I like.
On Mon, Mar 21, 2022, at 4:53 AM, thutt@harp-project.com wrote:
Joerg writes:
{32} will be translated to (0x1u << 32)
I‘m not a C specialist, but shouldn‘t it read (0x1ull << 32)
It varies from compiler to compiler. With gcc, this will facilitate shifting more than 31 bits.
But, shifting more than the number of bits in an integer is entering into 'undefined behavior' (or is it 'implementation defined') territory.
-- I have never met a beet which I like.
Taylor Hutt? The Oberon-2 paladin? :-)
participants (4)
-
Diego Sardina -
Joe Turner -
Joerg -
thutt＠harp-project.com