ooc-compiler

[ooc-compiler] Why are parameter comments removed?

[August K. <fus...@co...>]

Hello all,

When generating documentation with oo2c, parameter comments like in e.g.

    PROCEDURE P(VAR (*in*) a: ARRAY OF LONGINT);

are removed. Why?


August

Re: [ooc-compiler] WITH statement and parametric types

[Michael v. A. <mic...@gm...>]

On 07/10/05, Michael van Acken <mic...@gm...> wrote:
> Sorry, the recent 2.1.9 release does not run the test case below
> correctly.  I messed up my test suite _again_  by only running type
> tests with simple type variables  :-/

The attached patch should resolve this issue.  Please give it a try.

-- mva

Re: [ooc-compiler] WITH statement and parametric types

[Michael v. A. <mic...@gm...>]

Sorry, the recent 2.1.9 release does not run the test case below
correctly.  I messed up my test suite _again_  by only running type
tests with simple type variables  :-/

I'll try to find a solution over the weekend.

-- mva

On 26/06/05, vedmed <ve...@in...> wrote:
> I declare parametric type, and want to redefine procedure "Equals":
>
> MODULE Test;
>
> IMPORT Object, Out;
>
> TYPE
>    Alp(T: Object.Object) =3D POINTER TO AlpDesc(T);
>    AlpDesc(T: Object.Object) =3D RECORD(Object.ObjectDesc)
>      val: LONGINT;
>    END;
>
>    Bet =3D POINTER TO BetDesc;
>    BetDesc =3D RECORD(Object.ObjectDesc)
>
>    END;
>
>    Gam =3D Alp(Bet);
>
> VAR
>    g1: Gam;
>    g2: Gam;
>
> PROCEDURE (a: Alp(T)) INIT*(val: INTEGER);
> BEGIN
>    a.val :=3D val;
> END INIT;
>
> PROCEDURE (x: Alp(T)) Equals*(y: Object.Object): BOOLEAN;
> BEGIN
>    IF y =3D NIL THEN
>      RETURN FALSE;
>    ELSE
>      WITH y: Alp(T) DO
>        RETURN x.val =3D y.val;
>      ELSE
>        RETURN FALSE;
>      END;
>    END;
> END Equals;
>
> BEGIN
>    g1 :=3D NEW(Gam, 1);
>    g2 :=3D NEW(Gam, 1);
>    IF g1.Equals(g2) THEN
>      Out.String('equals'); Out.Ln();
>    ELSE
>      Out.String('not equals'); Out.Ln();
>    END;
> END Test.
>
> But in this example "Equal" always return FALSE, because of WITH
> statement can not recognize parameter "y" as value of type "Alp" or
> "Gam". Expressions "WITH y: Alp DO" and "WITH y: Alp(Object.Object) DO"
> also not works. So I can't see a way how to get access to field "val" of
> parameter "y". I don't know it is bug of compiler or some logic problem.
> I suppose that full check of type and all of him parameters is difficult
> task for compiler and can slow down compiled programs, but I assume,
> that in most cases will be enough only checks of base type.
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclic=
k
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
>

[ooc-compiler] oo2c-2.1.9 released

[Michael v. A. <Mic...@de...>]

(oo2c) Within a type-bound procedure, type variables can now be used
on the right hand side of a type test or type guard.

(oo2c) Fix crash due to failing error recovery (#1227684, #1227687),
as well as an overeager assertion.

(oo2c) Always provide ` --tag=CXX' when calling libtool.

(oob) Fix output syntax of procedure types.
 
(ADT:Dictionary) New method Lookup() that returns a boolean value to
indicate success or failure.  The looked up value is returned through
a VAR parameter.  (Thanks to vedmed)

(OS:HostPath) MINGW: Allocate temporary strings in Oberon-2 arrays,
rather than C arrays.  This fixes a serious bug in the Windows path
normalisation functions, which can cause failures on some hardware due
to due to array descriptors being absent (run-time system uses illegal
array length value).

(RT0) Change argv to use the type C.charPtr2d

The generated C code and (for the most part) the library modules
written in C should not produce warnings when compiled with gcc4.

-- mva

AW: [ooc-compiler] Oberon string to C string

[<tim...@ma...>]

Hallo!

Please be carefull with defining INTERFACE modules for external code.
Defining for example a method puts where puts is a macro in C will not =
work.
You must be sure that everything you define in an INTERFACE module has =
a
symbol (if I remeber correctly I had this porblems with writing an =
interface
for curses)!

For not that simple interfaces I would suggest to write a FOREIGN =
module,
since this works around this problem and  at the same time allows you =
to
create a more streamlined interface.

--=20
Gru=DF...=20
       Tim.

Re: [ooc-compiler] Oberon string to C string

[<sgr...@ii...>]

Hi August,

> How do I pass an Oberon string to a C function taking a (constant) 
> string parameter? The Oberon code generated by the C header converter 
> H2O seems to use `POINTER [CSTRING] TO ARRAY OF CHAR' for `char *',

That is correct. CSTRING declares that a pointer type is really a C string, 
and allows you to pass string literals as parameters.

If you want to see some examples, check out the Windows module from the 
VisualOberon repository. It has CSTRING declarations for string parameters of 
Win32 functions, and these are called in the example programs. Still works for 
me with the current version of oo2c.

> however with the code below I get a warning from oo2c: "conflicting 
> types for built-in function `puts'".
> 
>     MODULE Test;
>        IMPORT Interface;
>     BEGIN
>        Interface.puts("Hello there!")
>     END Test.
> 
>     MODULE Interface [INTERFACE "C"];
>        TYPE String* = POINTER [CSTRING] TO ARRAY OF CHAR;
>        PROCEDURE puts*(s: String);
>     END Interface.

oo2c builds prototypes for the procedures declared in your interface module. 
My guess is that the message you are seeing is from the C compiler. Its 
probably because your definition of puts conflicts with the version in stdio.h.

Under mingw32, puts is defined like this:
  _CRTIMP int __cdecl     puts (const char*);

Therefore, you should probably have declared:
  PROCEDURE puts*(s: String) : LONGINT;

oo2c won't generate a "const" declaration, so you may not be able to get a 
completely compatible declaration.

This is a slightly unusual case, as the generated Interface.oh/Interface.d 
declarations are only really intended to be used in Oberon-2 or FOREIGN 
modules. I suspect that stdio.h is somehow included via the standard oo2c 
headers. Check if the above declaration fixes your problem. If not, you might 
just have to live with the fact that the declarations cannot be made to 
completely agree.

Hope this helps.

Cheers,
  Stewart

[ooc-compiler] Oberon string to C string

[August K. <fus...@co...>]

Hi all,

How do I pass an Oberon string to a C function taking a (constant) 
string parameter? The Oberon code generated by the C header converter 
H2O seems to use `POINTER [CSTRING] TO ARRAY OF CHAR' for `char *', 
however with the code below I get a warning from oo2c: "conflicting 
types for built-in function `puts'".

    MODULE Test;
       IMPORT Interface;
    BEGIN
       Interface.puts("Hello there!")
    END Test.

    MODULE Interface [INTERFACE "C"];
       TYPE String* = POINTER [CSTRING] TO ARRAY OF CHAR;
       PROCEDURE puts*(s: String);
    END Interface.


Regards,

August

Re: [ooc-compiler] SYSTEM.VAL bug?

[akarl <fus...@co...>]

Michael van Acken wrote:
> On 30/08/05, akarl <fus...@co...> wrote:
>>Why is the last statement in Test.Mod invalid?
>>
>>[src]$ cat Test.Mod
>>MODULE Test;
>>    IMPORT SYSTEM;
>>    VAR s: SET; n: SHORTINT;
>>BEGIN
>>    n := 1;
>>    s := SYSTEM.VAL(SET, LONG(LONG(n)));
>>    s := SYSTEM.VAL(SET, LONG(LONG(1)))
> 
> 
> For an integer constant, oo2c always uses the smallest integer
> type that can hold it.  As LONG() is an identity operation, it does
> not change the type of integer constants: SIZE(1)=SIZE(LONG(1))=1
> 
> For a broader discussion of this, please see appendix B of Patrik Reali's 
> dissertation at http://www.inf.ethz.ch/personal/reali/

OK, thanks.

August

Re: [ooc-compiler] Compiler bug with multiple type guards

[Michael v. A. <mic...@gm...>]

You are right, the compiler should accept this.
I will see to it.  Thanks!

-- mva


On 30/08/05, akarl <fus...@co...> wrote:
> [src]$ cat Test.Mod
> MODULE Test;
>=20
>     IMPORT Out;
>=20
>     TYPE
>        T0 =3D POINTER TO T0Desc;
>        T0Desc =3D RECORD x: LONGINT END;
>=20
>        T1 =3D POINTER TO T1Desc;
>        T1Desc =3D RECORD (T0Desc) y: LONGINT END;
>=20
>        T2 =3D POINTER TO T2Desc;
>        T2Desc =3D RECORD (T1Desc) z: LONGINT END;
>=20
>     VAR
>        t0: T0;
>        t2: T2;
>=20
> BEGIN
>     NEW(t2);
>     t0 :=3D t2;
>     Out.Int(t0(T1)(T2).z, 0);
>     Out.Ln
> END Test.
>=20
> [src]$ make -k
> oo2c -M -r .. Test.Mod
>=20
> ##
> ## Runtime error in module OOC:SSA:IRtoSSA at pos 22887
> ## Assertion failed, code 127
> ##
> 0: <some path>/lib/liboo2c.so.3 [0xc09070]
> 1: <some path>/lib/liboo2c.so.3(_runtime_error+0x3a) [0xc090fe]
> 2: <some path>/lib/liboo2c.so.3(RT0__Halt+0) [0xc0977c]
> 3: oo2c [0x80e84a2]
> 4: oo2c [0x80e7324]
> 5: oo2c [0x80e6cd7]
> 6: oo2c [0x80e69aa]
> 7: oo2c [0x80e637f]
> 8: oo2c [0x80e9295]
> 9: oo2c [0x8104a98]
> 10: oo2c [0x80d6652]
> 11: oo2c [0x80d6b79]
> 12: oo2c [0x8123735]
> 13: oo2c [0x8123a86]
> 14: oo2c [0x812577d]
> 15: oo2c [0x8125146]
> 16: oo2c [0x81258bc]
> 17: oo2c [0x8128c8a]
> 18: oo2c [0x81290e5]
> 19: oo2c [0x812911b]
> 20: /lib/libc.so.6(__libc_start_main+0xc6) [0x9a9de6]
> make: *** [Test] Error 127
>=20
>=20
> Regards,
>=20
> August
>=20
>=20
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic=
es
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q=
A
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> ooc-compiler mailing list
> ooc...@li...
> https://lists.sourceforge.net/lists/listinfo/ooc-compiler
>

Re: [ooc-compiler] SYSTEM.VAL bug?

[Michael v. A. <mic...@gm...>]

On 30/08/05, akarl <fus...@co...> wrote:
> Hi all,
>=20
> Why is the last statement in Test.Mod invalid?
>=20
> [src]$ cat Test.Mod
> MODULE Test;
>     IMPORT SYSTEM;
>     VAR s: SET; n: SHORTINT;
> BEGIN
>     n :=3D 1;
>     s :=3D SYSTEM.VAL(SET, LONG(LONG(n)));
>     s :=3D SYSTEM.VAL(SET, LONG(LONG(1)))

For an integer constant, oo2c always uses the smallest integer
type that can hold it.  As LONG() is an identity operation, it does
not change the type of integer constants: SIZE(1)=3DSIZE(LONG(1))=3D1

For a broader discussion of this, please see appendix B of Patrik Reali's=
=20
dissertation at http://www.inf.ethz.ch/personal/reali/

-- mva

[ooc-compiler] Compiler bug with multiple type guards

[akarl <fus...@co...>]

[src]$ cat Test.Mod
MODULE Test;

    IMPORT Out;

    TYPE
       T0 = POINTER TO T0Desc;
       T0Desc = RECORD x: LONGINT END;

       T1 = POINTER TO T1Desc;
       T1Desc = RECORD (T0Desc) y: LONGINT END;

       T2 = POINTER TO T2Desc;
       T2Desc = RECORD (T1Desc) z: LONGINT END;

    VAR
       t0: T0;
       t2: T2;

BEGIN
    NEW(t2);
    t0 := t2;
    Out.Int(t0(T1)(T2).z, 0);
    Out.Ln
END Test.

[src]$ make -k
oo2c -M -r .. Test.Mod

##
## Runtime error in module OOC:SSA:IRtoSSA at pos 22887
## Assertion failed, code 127
##
0: <some path>/lib/liboo2c.so.3 [0xc09070]
1: <some path>/lib/liboo2c.so.3(_runtime_error+0x3a) [0xc090fe]
2: <some path>/lib/liboo2c.so.3(RT0__Halt+0) [0xc0977c]
3: oo2c [0x80e84a2]
4: oo2c [0x80e7324]
5: oo2c [0x80e6cd7]
6: oo2c [0x80e69aa]
7: oo2c [0x80e637f]
8: oo2c [0x80e9295]
9: oo2c [0x8104a98]
10: oo2c [0x80d6652]
11: oo2c [0x80d6b79]
12: oo2c [0x8123735]
13: oo2c [0x8123a86]
14: oo2c [0x812577d]
15: oo2c [0x8125146]
16: oo2c [0x81258bc]
17: oo2c [0x8128c8a]
18: oo2c [0x81290e5]
19: oo2c [0x812911b]
20: /lib/libc.so.6(__libc_start_main+0xc6) [0x9a9de6]
make: *** [Test] Error 127


Regards,

August

[ooc-compiler] SYSTEM.VAL bug?

[akarl <fus...@co...>]

Hi all,

Why is the last statement in Test.Mod invalid?

[src]$ cat Test.Mod
MODULE Test;
    IMPORT SYSTEM;
    VAR s: SET; n: SHORTINT;
BEGIN
    n := 1;
    s := SYSTEM.VAL(SET, LONG(LONG(n)));
    s := SYSTEM.VAL(SET, LONG(LONG(1)))
END Test.

[src]$ oo2c -M -r .. Test.Mod
Test.Mod:7:35: Size mismatch between type and expression


Regards,

August

[ooc-compiler] OOC and gcc 4.0

[akarl <fus...@co...>]

Hi all,

Seems like GCC 4.0 doesn't like the C files generated by oo2c:

[src]$ cat Test.Mod
MODULE Test;
    IMPORT Out;
BEGIN
    Out.String("abc");
    Out.Ln
END Test.

[src]$ make -k
oo2c -M -r .. Test.Mod
/home/august/prog/oberon/test/obj/Test.c: In function =91OOC_Test_init=92=
:
/home/august/prog/oberon/test/obj/Test.c:7: warning: pointer targets in=20
passing
argument 1 of =91Out__String=92 differ in signedness

I have compiled OOC (version 2.1.8) with GCC 4.0.


Regards,

August

Re: [ooc-compiler] WITH statement and parametric types

[Michael v. A. <mic...@gm...>]

On 7/3/05, Peter Fr=F6hlich <ph...@cs...> wrote:
> Hi all,
>=20
> On Jul 3, 2005, at 07:50, Michael van Acken wrote:
>=20
> > The current implementation cannot cope with types on the right hand
> > side of a type test that include a type variable.  It is fundamentally
> > flawed.  Unfortunately I botched a test case half a year ago, or I
> > would
> > have known this earlier.
>=20
> Is this purely an implementation issue or is there a problem with the
> Szyperski/Roe proposal itself (which I gather is what you implemented
> for OOC)? I never tried implementing it myself, but it *looked* solid
> at the time. Any comments?

Yes, it is an implementation issue, and no, it has nothing to do with
Szyperski/Roe.

OOC's implementation is for the most part derived from Generic Java,
but carries type information into the run-time environment as well.
Neither GJ nor S/R have a run-time component, if I remember correctly.

-- mva

Re: [ooc-compiler] WITH statement and parametric types

[<ph...@cs...>]

Hi all,

On Jul 3, 2005, at 07:50, Michael van Acken wrote:

> The current implementation cannot cope with types on the right hand
> side of a type test that include a type variable.  It is fundamentally
> flawed.  Unfortunately I botched a test case half a year ago, or I 
> would
> have known this earlier.

Is this purely an implementation issue or is there a problem with the 
Szyperski/Roe proposal itself (which I gather is what you implemented 
for OOC)? I never tried implementing it myself, but it *looked* solid 
at the time. Any comments?

Peter
--
Peter H. Froehlich <><><><><><> http://www.cs.ucr.edu/~phf/
OpenPGP: ABC2 9BCC 1445 86E9 4D59  F532 A8B2 BFAE 342B E9D9

Re: [ooc-compiler] WITH statement and parametric types

[Michael v. A. <mic...@gm...>]

On 6/26/05, vedmed <ve...@in...> wrote:
> I declare parametric type, and want to redefine procedure "Equals":
> [...]
>=20
> But in this example "Equal" always return FALSE, because of WITH
> statement can not recognize parameter "y" as value of type "Alp" or
> "Gam". Expressions "WITH y: Alp DO" and "WITH y: Alp(Object.Object) DO"
> also not works. So I can't see a way how to get access to field "val" of
> parameter "y". I don't know it is bug of compiler or some logic problem.
> I suppose that full check of type and all of him parameters is difficult
> task for compiler and can slow down compiled programs, but I assume,
> that in most cases will be enough only checks of base type.

The current implementation cannot cope with types on the right hand
side of a type test that include a type variable.  It is fundamentally=20
flawed.  Unfortunately I botched a test case half a year ago, or I would
have known this earlier.

I don't know a workaround, and there is no easy fix.  I will have to
think about this some more.

-- mva

Re: [ooc-compiler] Usage of ADT:Dictionary

[Michael v. A. <mic...@gm...>]

On 6/26/05, vedmed <ve...@in...> wrote:
> The library oo2c contains very useful object ADT:Dictionary.Dictionary.
> This object has procedure of check of existence of a key and procedure
> of reception of value on a key, but does not contain procedure returning
> simultaneously value on a key, and an attribute of existence instead of
> exception. It compels in cases similar to
> ...
[...]
> ...
>  I can easily add manually such procedure in module Dictionary, but
> would like to see it in structure of standard library. However if there
> are basic objections against existence of such procedure I would like
> them to hear.

No objections from my side.  I would prefer the name "Lookup" instead=20
of "Find", though.  This conflicts with the current private Lookup() method=
,
but its name can be easily changed.

If you provide me with a patch for ADT:Dictionary and the other three
dictionary modules (ADT:Dictionary:AddressKey and so on), then I will
add it to the std library.

-- mva

[ooc-compiler] WITH statement and parametric types

[vedmed <ve...@in...>]

I declare parametric type, and want to redefine procedure "Equals":

MODULE Test;

IMPORT Object, Out;

TYPE
   Alp(T: Object.Object) = POINTER TO AlpDesc(T);
   AlpDesc(T: Object.Object) = RECORD(Object.ObjectDesc)
     val: LONGINT;
   END;

   Bet = POINTER TO BetDesc;
   BetDesc = RECORD(Object.ObjectDesc)

   END;

   Gam = Alp(Bet);

VAR
   g1: Gam;
   g2: Gam;

PROCEDURE (a: Alp(T)) INIT*(val: INTEGER);
BEGIN
   a.val := val;
END INIT;

PROCEDURE (x: Alp(T)) Equals*(y: Object.Object): BOOLEAN;
BEGIN
   IF y = NIL THEN
     RETURN FALSE;
   ELSE
     WITH y: Alp(T) DO
       RETURN x.val = y.val;
     ELSE
       RETURN FALSE;
     END;
   END;
END Equals;

BEGIN
   g1 := NEW(Gam, 1);
   g2 := NEW(Gam, 1);
   IF g1.Equals(g2) THEN
     Out.String('equals'); Out.Ln();
   ELSE
     Out.String('not equals'); Out.Ln();
   END;
END Test.

But in this example "Equal" always return FALSE, because of WITH 
statement can not recognize parameter "y" as value of type "Alp" or 
"Gam". Expressions "WITH y: Alp DO" and "WITH y: Alp(Object.Object) DO" 
also not works. So I can't see a way how to get access to field "val" of 
parameter "y". I don't know it is bug of compiler or some logic problem. 
I suppose that full check of type and all of him parameters is difficult 
task for compiler and can slow down compiled programs, but I assume, 
that in most cases will be enough only checks of base type.

[ooc-compiler] Usage of ADT:Dictionary

[vedmed <ve...@in...>]

The library oo2c contains very useful object ADT:Dictionary.Dictionary. 
This object has procedure of check of existence of a key and procedure 
of reception of value on a key, but does not contain procedure returning 
simultaneously value on a key, and an attribute of existence instead of 
exception. It compels in cases similar to
...
  d: SomeDictionary;
...
IF d.HasKey(key) THEN
  val := d.Get(key);
  val.DoSomething();
ELSE
...
perform search under the dictionary twice, instead of once, like
...
IF d.Find(key, val) THEN
  val.DoSomething();
ELSE
...
 I can easily add manually such procedure in module Dictionary, but 
would like to see it in structure of standard library. However if there 
are basic objections against existence of such procedure I would like 
them to hear.

Re: [ooc-compiler] Unsafe pointers on the stack

[August K. <fus...@co...>]

Stewart Greenhill wrote:
> 
> Hi August,
> 
>> If I compile and run the following program I get a segmentation fault 
>> rather that a run time exception.
>>
>>    MODULE Test;
>>       PROCEDURE P;
>>          VAR p: POINTER TO ARRAY OF LONGINT;
>>       BEGIN
>>          p[0] := 1
>>       END P;
>>    BEGIN
>>       P
>>    END Test.
>>
>> So in this regard the above program compiled with OOC is just as 
>> unsafe as a C program. Wasn't the elimination of wild pointers one of 
>> the design criteria of Oberon?
> 
> 
> OOC generates the following warning for this code.
> 
> In file src/Test.Mod:
>       PROCEDURE P;
>          VAR p: POINTER TO ARRAY OF LONGINT;
>       BEGIN
>          p[0] := 1
> #--------^
> # 5:  Warning: Undefined variable
>       END P;
>    BEGIN
>       P
> 
> OOC V1 used to support the optional initialisation of stack-based 
> variables (obviously, with a performance cost) via the "Initialize := 
> TRUE" pragma. I'm not sure if this feature made it into the V2 compiler. 
> Generally, if you check the compiler warnings it will pick up most of 
> these cases.
> 
> Cheers,
>   Stewart
> 
> 

OK, thanks. Maybe a warning is enough.

-- 
august

Re: [ooc-compiler] Unsafe pointers on the stack

[Stewart G. <sgr...@ii...>]

Hi August,

> If I compile and run the following program I get a segmentation fault 
> rather that a run time exception.
>
>    MODULE Test;
>       PROCEDURE P;
>          VAR p: POINTER TO ARRAY OF LONGINT;
>       BEGIN
>          p[0] := 1
>       END P;
>    BEGIN
>       P
>    END Test.
>
> So in this regard the above program compiled with OOC is just as 
> unsafe as a C program. Wasn't the elimination of wild pointers one of 
> the design criteria of Oberon?

OOC generates the following warning for this code.

In file src/Test.Mod:
       PROCEDURE P;
          VAR p: POINTER TO ARRAY OF LONGINT;
       BEGIN
          p[0] := 1
#--------^
# 5:  Warning: Undefined variable
       END P;
    BEGIN
       P

OOC V1 used to support the optional initialisation of stack-based 
variables (obviously, with a performance cost) via the "Initialize := 
TRUE" pragma. I'm not sure if this feature made it into the V2 
compiler. Generally, if you check the compiler warnings it will pick up 
most of these cases.

Cheers,
   Stewart

Re: [ooc-compiler] Unsafe pointers on the stack

[Isaac G. <ig...@ya...>]

--- August Karlstrom <fus...@co...> wrote:
> If I compile and run the following program I get a segmentation fault
> rather that a run time exception.
> 
>     MODULE Test;
>        PROCEDURE P;
>           VAR p: POINTER TO ARRAY OF LONGINT;
>        BEGIN
>           p[0] := 1
>        END P;
>     BEGIN
>        P
>     END Test.
> 
> So in this regard the above program compiled with OOC is just as
> unsafe as a C program. Wasn't the elimination of wild pointers one of
> the design criteria of Oberon?

fyi XDS Oberon-2 gives 2 compile-time warnings
5:7 possibly used before definition "p"
5:8 NIL dereference


		
__________________________________ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new Resources site
http://smallbusiness.yahoo.com/resources/

[ooc-compiler] Unsafe pointers on the stack

[August K. <fus...@co...>]

If I compile and run the following program I get a segmentation fault 
rather that a run time exception.

    MODULE Test;
       PROCEDURE P;
          VAR p: POINTER TO ARRAY OF LONGINT;
       BEGIN
          p[0] := 1
       END P;
    BEGIN
       P
    END Test.

So in this regard the above program compiled with OOC is just as unsafe 
as a C program. Wasn't the elimination of wild pointers one of the 
design criteria of Oberon?

-- August

Re: [ooc-compiler] Position of runtime error

[Stewart G. <sgr...@ii...>]

On 15/05/2005, at 6:06 AM, August Karlstrom wrote:

> Stewart Greenhill wrote:
>> You can get this information using the 'ooef' utility.
>> For example,
>>   ooef src/Test.Mod 171
>> This gives you the source code context (the default behaviour, also 
>> available via the --context switch). If you just want to know the 
>> line and column you can do:
>>   ooef --linecol src/Test.Mod 171
>
> Ok, thanks. I still don't understand why the runtime can't output line 
> and column as oo2c does by default.

It could output this information, but that would require some changes 
to the way source position is encoded for run-time errors. Currently, 
oo2c uses the module descriptor and a single integer (ie. character 
position). I think a single integer would still be enough if (for 
example) 8 bits were used for column and 24 bits for row. The current 
solution works well for me. Usually, I want the line number and a 
little bit of source code context so I have to run an external program 
anyway.

Cheers,
   Stewart

Re: [ooc-compiler] Position of runtime error

[August K. <fus...@co...>]

Stewart Greenhill wrote:
> Hi August,
> 
>> In runtime error messages, OOC outputs the position where the error 
>> occurred but no info on line (or column) number, for instance:
>>
>> ##
>> ## Runtime error in module Test at pos 171
>> ## Dereference of NIL
>> ##
>>
>> It's kind of hard to find the position in an editor that lacks Emacs' 
>> `goto-char' function and even for Emacs users it would be more 
>> convenient with a line (and a column) number.
> 
> [...]
> 
> You can get this information using the 'ooef' utility.
> 
> For example,
>   ooef src/Test.Mod 171
> 
> This gives you the source code context (the default behaviour, also 
> available via the --context switch). If you just want to know the line 
> and column you can do:
>   ooef --linecol src/Test.Mod 171

Ok, thanks. I still don't understand why the runtime can't output line 
and column as oo2c does by default.

-- 
august