Re: [ooc-compiler] Language limitation or a compiler bug?

[Alexander I. <aj...@ya...>]

Hello!

>    I found that it's impossible to do "CONST x = SYSTEM.VAL (SET, 10)",
>    because "10" is 1 byte, and SET is 4 bytes. And if I do "CONST x = 
>    SYSTEM.VAL (SET, LONG(LONG(10)))", then suddenly I get "expression
>    is not constant error".
>    Somehow "10" is a constant, and "LONG(LONG(10))" is not.
>  
>    Is this a compiler bug or an intentional behaviour?

  I was wrong, the problem is not only with LONG(LONG()), but with SYSTEM.VAL as well.

  Here is the only way to convert integer constant value 10 to SET I found:

VAR
   set: SET;
   long: LONGINT;
BEGIN
   long := 10;
   attr := SYSTEM.VAL (SET, long);

  If you try to use "10" instead of "long" in the last line, you'll get the size mismatch error
  ("Size mismatch between type and expression"). Presumably this is because 10 is 1 byte,
  and SET is 4 bytes. OK, sounds reasonable.

  But shouldn't it be possible to use LONG() for size promotion? The following also compiles
  without errors (LONGINT replaced with SHORTINT, added two LONG() calls):

VAR
   set: SET;
   short: SHORTINT;
BEGIN
   short := 10;
   set := SYSTEM.VAL (SET, LONG(LONG(short)));

  Now there are two things that surprize me:
1. LONG(LONG(10)) does not produce a LONGINT constant 10. And neither does "0000000AH";
2. SYSTEM.VAL can't be used in a constant definition (more on that later).

  Is it at all possible to create a constant of a given size? We have 1.E0 and 1.D0 to distinguish
  between REAL and LONGREAL constants, but do we have a mechanism to say, I need "10"
  in a LONGINT? SYSTEM.VAL (LONGINT, short) fails with the same size mismatch error.

  The SYSTEM.VAL surprize boils down to this:

CONST num = SYSTEM.VAL (SHORTINT, 10);

  This produces the following error: "Expression is not constant". In this example the SYSTEM.VAL
  call is a no-op. My question is: what is not constant about it?
  Doesn't SYSTEM.VAL ALWAYS produce constant result no matter what type it casts to?

  I'd like to ask everyone, Michael van Acken in particular, for advice on this situation. I'm willing
  to dig into the sources if this is something to be fixed.

---=====---
 Alexander