[BlackBox] Compiler trap.

[DddIzer]

По моему не выйдет - там же еще выравнивание небось будет.

а х.з. но в любом случае это будет эксплоитом (язык не определяет  структуру данных на низком уровне)... что не гуд...

[Berserker]

В С++ та же проблема без привязки к конкретному компилятору, не так ли? __declspec(align(1))

[valexey_u]

В С++ та же проблема без привязки к конкретному компилятору, не так ли? __declspec(align(1))

На самом деле, не совсем:
http://www.stroustrup.com/C++11FAQ.html#align
http://www.stroustrup.com/C++11FAQ.html#attributes

[valexey_u]

Возвращаясь к первоначальному топику - пришел ответ от Oberon microsystems AG:

Dear Alexey,

thank you very much for your error report.

We will analyze the problem and hope to correct it in the course of our maintenance activity.

You are probably already aware of a possible workaround along the following lines:

        PROCEDURE Blur(IN in : Frame; OUT out : Frame);
        VAR
                x,y,c,o: INTEGER;
        BEGIN
                FOR y:=1 TO height-2 DO
                        FOR x:=1 TO width-2 DO
                                FOR c:=red TO blue DO
                                        o:=(ORD(in[Index(x,y-1,c)])
                                                + ORD(in[Index(x,y+1,c)])
                                                + ORD(in[Index(x-1,y,c)])
                                                + ORD(in[Index(x+1,y,c)])) DIV 4;
                                        out[Index(x,y,c)] := SHORT(CHR(o));
                                END;
                        END;
                END;
        END Blur;

Thanks again and with best regards,
Marc Frei

[ilovb]

Интересно как скоро будет фикс.

[Berserker]

valexey_u, десятилетия и тонны софта до версии С++11х, так что это не показатель. То же самое и с новыми типами вроде int32_least_t, они нигде не используются, а нужно, чтобы весь код был с их применением.

[valexey_u]

Интересно как скоро будет фикс.

Ответил им. Дал быстрый фикс от maliya, и ссылку на эту ветку.

[igor]

Ответил им. Дал быстрый фикс от maliya, и ссылку на эту ветку.

Представляю их лица, когда они переведут эту ветку... (Привет kkk и Ди-ди-дАйзеру)

[DddIzer]

Ответил им. Дал быстрый фикс от maliya, и ссылку на эту ветку.

Представляю их лица, когда они переведут эту ветку... (Привет kkk и Ди-ди-дАйзеру)

  да ладно... ради общего же дела старались (по крайней мере я, увидев бы эту ветку на их месте...-- сказал себе.. блин , а все таки здорово, что наше поделье через 15 лет , вызывает такие эмоциии - ну не круто ли!!!)

[DddIzer]

... и уж они явно лучше чем "лизоблюдские" реляции из коровника, для человека который более менее  адекватно оценивает свой труд...(но это , разумеется , ИМХО)

[DddIzer]

В С++ та же проблема без привязки к конкретному компилятору, не так ли? __declspec(align(1))

где то так.. ,  но вроде как еще в допотопных версиях Паскаля проблема решалась использованием packed records.. на уровне языка.

[Berserker]

Небольшое отклонение от темы.
FreePascal, VirtualPascal, Delphi — проблемы нет, PACKED справляется с записями и массивами. То же самое с соглашениями о вызове. Все их применяют, но лишь стандарт С++ не знает об их существовании. Если целевая платформа не поддерживает определённое соглашение (разрядность, операцию умножения или любой другой элемент ЯП) достаточно выдать ошибку компиляции. Но STDCALL — он и в Африке STDCALL.

Я сперва использовал __declspec(alegn(1)), потом перешёл на #pragma pack(push, 1) из-за разичий в GCC и Студии.

[DddIzer]

перешёл на #pragma pack(push, 1) из-за разичий в GCC и Студии.

  аналогично.. только аligned не  использовал ни разу..

[DddIzer]

Интересно как скоро будет фикс.

а вот это , действительно интересно...

[valexey_u]

Небольшое отклонение от темы.
FreePascal, VirtualPascal, Delphi — проблемы нет, PACKED справляется с записями и массивами. То же самое с соглашениями о вызове. Все их применяют, но лишь стандарт С++ не знает об их существовании. Если целевая платформа не поддерживает определённое соглашение (разрядность, операцию умножения или любой другой элемент ЯП) достаточно выдать ошибку компиляции. Но STDCALL — он и в Африке STDCALL.

Я сперва использовал __declspec(alegn(1)), потом перешёл на #pragma pack(push, 1) из-за разичий в GCC и Студии.

FreePascal, VirtualPascal, Delphi - не следуют какому-либо стандарту вообще. Это конкретные реализации со своими заморочками, не следующие какому-либо стандарту. Реализации сравнивать со стандартом на язык как-то странно. Ну, то есть корректно было бы сравнивать FreePascal c g++, Delphi с MSVS, VirtualPascal с Intel C++ Compiler и так далее.

Ну и я же не даром две ссылки привел - стандарт С++ теперь про выравнивание знает. Но прибить гвоздями ABI для универсального языка не представляется возможным.