Hello, Am 02.07.2023 um 07:14 schrieb peter@easthope.ca:
ETH Oberon (2019) Language Report p. 56, 12.1.1. Conversions LONG(x) ... DEPRECATED
Page 21: Where there is no implicit compatibility between types, they can be converted with an explicit conversion. The type name itself can be used for a type conversion.
oberon/source/Unix.Oberon.NetSystem.Mod PROCEDURE OpenConnection* ( VAR conn: Connection; locPort: UNSIGNED16; remIP: IPAdr; remPort: UNSIGNED16; VAR res: SIGNED16 ); VAR r: SIGNED32; BEGIN IF remPort = anyport THEN remIP := anyIP END; NEW( conn ); conn.Open( locPort, remIP, LONG(remPort) MOD 10000H, r ); IF r = TCP.Ok THEN res := done ELSE res := error END END OpenConnection;
If LONG is removed, conn.Open won't agree on the type of the 3rd parameter. Is there another way to convert a type? The declaration of Open also needs a change?
conn.Open( locPort, remIP, UNSIGNED32(remPort) MOD 10000H, r ); Regards, Michael
Hi I can‘t answer the question, why the author of this source code uses „remPort“ with an explicit conversion and „locPort“ with the implicit conversion, the compiler generates. br Jörg
Am 02.07.2023 um 14:00 schrieb Michael Schierl <schierlm@gmx.de>:
Hello,
Am 02.07.2023 um 07:14 schrieb peter@easthope.ca: ETH Oberon (2019) Language Report p. 56, 12.1.1. Conversions LONG(x) ... DEPRECATED
Page 21:
Where there is no implicit compatibility between types, they can be converted with an explicit conversion. The type name itself can be used for a type conversion.
oberon/source/Unix.Oberon.NetSystem.Mod PROCEDURE OpenConnection* ( VAR conn: Connection; locPort: UNSIGNED16; remIP: IPAdr; remPort: UNSIGNED16; VAR res: SIGNED16 ); VAR r: SIGNED32; BEGIN IF remPort = anyport THEN remIP := anyIP END; NEW( conn ); conn.Open( locPort, remIP, LONG(remPort) MOD 10000H, r ); IF r = TCP.Ok THEN res := done ELSE res := error END END OpenConnection;
If LONG is removed, conn.Open won't agree on the type of the 3rd parameter. Is there another way to convert a type? The declaration of Open also needs a change?
conn.Open( locPort, remIP, UNSIGNED32(remPort) MOD 10000H, r );
Regards,
Michael
-- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
Sergey It is clear that the connversion of signed16 —> signed32 max have the effect you described. However, in UDP/TCP messages you only transfer 16 bits of the port, so the status of the higher bits should not matter. If the remPort was signed16, I strongly assume locPort was signed16 as well. So why in one case explicit, in the other case implicit. The code does not make sense to me unless remPort and locPort had different types. br Jörg
Am 04.07.2023 um 18:52 schrieb Sergey Durmanov <serge.durmanov@yandex.ru>:
Hi,. because previously signed types were used for ports, and the remote port number could be greater than max(signed16), causing the sign bit to propagate. this code is now unnecessary.
02.07.2023, 22:52, "Joerg" <joerg.straube@iaeth.ch>: Hi
I can‘t answer the question, why the author of this source code uses „remPort“ with an explicit conversion and „locPort“ with the implicit conversion, the compiler generates.
br Jörg
https://lists.inf.ethz.ch/mailman/listinfo/oberon -- Oberon@lists.inf.ethz.ch mailing list for ETH Oberon and related systems https://lists.inf.ethz.ch/mailman/listinfo/oberon
participants (3)
-
Joerg -
Michael Schierl -
Sergey Durmanov