Чем Вирту WITH не угодил?

[ilovb]

Блин у меня даже прям слов нет... Одни эмоции....

[Kemet]

Может там, всё-таки, должно стоять
(n >= -700)
чтобы хотябы варнинги вывести потом

[Kemet]

Кстати, в ЧЯ1.5 код идентичен

[ilovb]

Скорее всего 302 должно быть без минуса просто. Они минус наверно в этих целях и использовали при написании компилятора.

Т.е. поставил минус - ошибка не выводится....

А вот специально они ентот минус оставили или случайно - это уже загадка.

[ilovb]

Кстати там это единственная ошибка с минусом

В этом можно убедиться сделав поиск: ctrl+F "err(-"

[Kemet]

Ну может в коммерческой версии минус меняется на плюс, а пипл и так схавает

[ilovb]

Тык это и есть коммерческая версия

[ilovb]

Хех... убрал минус и наш код перестал компилиться 

[ilovb]

Наверно лучше просто предупреждение выводить все таки....

p.s. Написал Ивану Денисову об этом косяке.

[Kemet]

p.s. Написал Ивану Денисову об этом косяке.

А кто это

[ilovb]

Координатор красноярской сборки BB 1.6
http://oberoncore.ru/projects/bb16ru-kras

[Илья Ермаков]

Илья, а тебе не надоело постоянно ругаться с людьми? Враждовать? Вещать истину? Особенно из-за такого пустяка как Оберон? 

Меня всегда удивляет/забавляет факт, что в жизни (на работе, в бизнесе, в моём городе, всюду, где я лично общаюсь с людьми) у меня практически нет конфликтов/врагов.
В Сети, однако, всё по-другому. Объяснений этому феномену найти пока не могу.

[ilovb]

Продублирую ценный пост:

Вы почитайте диссертацию Шиперски, там есть вещи и похуже. Например, в операторе WITH есть дефект. Там не гарантируется сохранность указателя, у которого уже определили тип, внутри тела WITH. Стр. 210:
Код:
TYPE
  P = POINTER TO R;   
  R = RECORD END;   
  P1= POINTER TO R1;   
  R1 = RECORD (R) x: INTEGER END;   
PROCEDURE F;   
  VAR p:P; p1:P1;   
  PROCEDURE G;   
  BEGIN NEW(p) END G;   
BEGIN NEW(p1);p:=p1;   
  WITH p: P1 DO   
    p.x:=0;  (*legal, since p has been   guarded to P1 *)
    G;       (*this destroys the assertion of the WITH guard*)   
    p.x := 42 (*havoc!!*)   
  END   
END F;

http://forum.oberoncore.ru/viewtopic.php?f=114&t=3836&start=40#p72578

[ilovb]

Oberon Type System Loopholes

WITH applied to designators of pointer type

It is possible to alter a guarded pointer variable within the scope of a guarding WITH statement. For example:
TYPE
 P = POINTER TO R;
 R = RECORD END;
 P1 = POINTER TO R1;
 R1 = RECORD (R) x: INTEGER END;

PROCEDURE F;
 VAR p: P; p1: P1;
 PROCEDURE G;
 BEGIN NEW(p) END G;
BEGIN
 NEW(p1);
 p := p1;
 WITH p: P1 DO
  p.x := 0;   (* legal, since p has been guarded to P1 *)
  G;       (* this destroys the assertion of the WITH guard *)
  p.x := 42;   (* havoc! *)
 END
END F;
So, it is best not to use the WITH statement on POINTER variables.
(Without a global (inter-module) consistancy check a compiler cannot accurately detect problematic code.)

SYSTEM.BYTE compatibility rule

The language defines a special compatibility rule (Oberon Language Report, Appendix A):
Module SYSTEM exports the data type BYTE. No representation of values is
specified. Instead, certain compatibility rules with other types are given:
(1) The type BYTE is compatible with CHAR and SHORTINT.
(2) If a formal variable parameter is of type ARRAY OF BYTE then the
    corresponding actual parameter may be of any type.
Rule 2 is a loophole in the type-system and should generally be avoided. For example, suppose the module Util has the following routine:
PROCEDURE Dummy (VAR x: ARRAY OF SYSTEM.BYTE);
If a client of Util calls Util.Dummy with a pointer as parameter, the invariant that pointers always point to a valid object on the heap (or are NIL) can be invalidated by Dummy since it can overwrite the pointer with any value. Note that the client didnt even import SYSTEM to declare itself an unsafe module.

SYSTEM.PTR compatibility rule

The Oberon-2 (not Oberon) language report (in appendix C) defines another special compatibility rule: Variables of any pointer type may be assigned to variables of type SYSTEM.PTR. If a formal variable parameter is of type PTR, the actual parameter may be of any pointer type.
This leads to the following loophole in the type-system: The type of a pointer-variable bound to a VAR parameter can be changed inside of a procedure (by an assignment), and the changed value be passed outside in violation of the type system.
Credits:

The material here is taken from the ETHOS book by C. Szyperski and from the Lagoona paper by M. Franz.

http://web.archive.org/web/20040530183405/http://www.math.tau.ac.il/~guy/Oberon/pitfalls.html

[ilovb]

Safety hazards in Oberon compilers and systems

This page lists problems with common implementations NOT with the language.
The page is a joint effort. If you know of any more problems or changes in the implementation that exhibit these problems please let me know. Thanks to S. Ludwig for most of the contents.

Numeric and stack overflow detection disabled by default

Some Oberon implementation dont by default generate code for detection of numeric overflows and stack overflows. If you have more details about specific implementations please let me know

POINTER TO ARRAY OF POINTER garbage collection problem

In some Oberon System implentations the garbage-collector doesnt mark the pointers within a POINTER TO ARRAY OF POINTER. This means the elements may be garbage-collected although they are still referenced.
Implementations exhibiting this problem (incomplete list): ETH Sparc V4, Amiga Oberon.

Stack garbage collection problem

This occurs when a procedure that has a VAR parameter which is the only reference left to a heap object. Example:
TYPE
   Node = POINTER TO NodeDesc;
   NodeDesc = RECORD val: INTEGER END;

VAR x: Node;

PROCEDURE Havoc(VAR val: INTEGER);
        VAR y: Node;
BEGIN
        x := NIL;   (* destroys last reference to x *)
        NEW(y);      (* may cause GC, thus freeing 'x', if val is not treated as a po
inter into 'x' *)
        INC(val)   (* memory havoc! *)
END Havoc;

BEGIN
        NEW(x); x.val := 15; Havoc(x.val)
END
Implementations exhibiting this problem (incomplete list): ETH DEC-Oberon V4, ETH HP-Oberon V4


Dangling procedure variables

Under all Oberon Systems it is possible to unload a module while there are procedure variables which refer to procedures in it.

http://web.archive.org/web/20040530181509/http://www.math.tau.ac.il/~guy/Oberon/compiler-probs.html