SAS/C Compiler, Stacksize errechnen

20 views
Skip to first unread message

Andreas M. Kirchwitz

unread,
Jan 6, 1993, 4:28:39 PM1/6/93
to
Another interesting problem!

Ich moechte (fuer eine Art "status" Befehl) die Stackgroesse von (CLI-)
Prozessen berechnen. Nun... ist einfach, meinen jetzt einige. Falsch.

In pr_Stacksize der Prozess-Struktur finde ich i.d.R. 3200 bei Programmen,
die einen Stack von 50000 haben. Manchmal stimmt pr_Stacksize aber auch
exakt mit dem ueberein, was "status" anzeigt. Warum ist das so? Wo ist
da die Logik?

In cli_DefaultStack der Cli-Struktur des Prozesses findet man die
Groesse, die urspruenglich vom aufrufenden Prozess vorgegeben wurde
(z.B. was man bei RunCommand() angibt). Na fein, das scheint wohl
"status" fuer seine Ausgabe zu verwenden. Aber mehr als eine "Vor-
gabe" ist das ja nicht.

Prima, jetzt mehr ins Detail:

Warum nicht in die INTERNA gehen und "task->tc_SPUpper-task->tc_SPLower"
der Task-Struktur berechnen. Da sollte man doch eigentlich den TATSAECH-
LICHEN Stack rauskriegen koennen. Manche Compiler (SAS/C, M2Amiga etc.)
spendieren einem Prozess ja auf Wunsch eine bestimmte vordefinierte (fest
eincompilierte) Stackgroesse.

Jetzt wird es interessant. Waehrend ich mit M2Amiga mit obigem Konstrukt
tatsaechlich an die Stackgroesse (eines M2Amiga-Programms) komme (egal ob
nun von der Shell vorgegeben oder fest eincompiliert), funktioniert das
mit SAS/C 6.1 komischerweise NICHT. Dort kriege ich immer genau die
HAELFTE der (vorgegebenen bzw. eincompilierten) Stackgroesse raus.

Warum? Wieso? Was mach ich falsch?

Ich habe mich ja nun daran gewoehnt, dass man bei SAS/C (im Gegensatz
zu M2Amiga) BPTR explizit wandeln muss in APTR. Aber was ist denn nun
an "task->tc_SPUpper-task->tc_SPLower" (zwei APTR) wieder so fatal?

Was mich halt interessiert: was fuer einen Stack haben die Prozesse
TATSAECHLICH. Das muss doch mit SAS/C zu schaffen sein!?

Thanks in advance... Andreas

--
IRC-Nick: | Andreas M. Kirchwitz, Seesener Str. 69, W-1000 Berlin 31, Germany
`bonzo' | Phone: +49 (0)30 873376, Mail: amk@{zikzak.in|cs.tu|fu}-berlin.de

Andreas M. Kirchwitz

unread,
Jan 6, 1993, 5:05:18 PM1/6/93
to
In article <nUNfs*K...@zikzak.in-berlin.de>, Andreas M. Kirchwitz writes:

> Ich habe mich ja nun daran gewoehnt, dass man bei SAS/C (im Gegensatz
> zu M2Amiga) BPTR explizit wandeln muss in APTR. Aber was ist denn nun
> an "task->tc_SPUpper-task->tc_SPLower" (zwei APTR) wieder so fatal?

Mit "(long)task->tc_SPUpper-(long)task->tc_SPLower" geht's. Warum?

Georg Sassen

unread,
Jan 7, 1993, 4:07:32 AM1/7/93
to
In article <KqOfs*P...@zikzak.in-berlin.de> a...@zikzak.in-berlin.de (Andreas M. Kirchwitz) writes:

>> Ich habe mich ja nun daran gewoehnt, dass man bei SAS/C (im Gegensatz
>> zu M2Amiga) BPTR explizit wandeln muss in APTR. Aber was ist denn nun
>> an "task->tc_SPUpper-task->tc_SPLower" (zwei APTR) wieder so fatal?
>
>Mit "(long)task->tc_SPUpper-(long)task->tc_SPLower" geht's. Warum?

Mit APTR darf man nicht rechnen, siehe exec/types.h:
/* WARNING: APTR was redefined for the V36 Includes! APTR is a */
/* 32-Bit Absolute Memory Pointer. C pointer math will not */
/* operate on APTR -- use "ULONG *" instead. */

Aber noch etwas anderes:

Der obige Weg zur Erkennung der Stackgröße funktioniert nur unter
Betriebssystemversionen >=2.0 und mit der Commodore-Shell. Unter 1.3,
aber auch mit der WShell 2.0 (die auch unter >=2.0 einen 1.3 CLI zu
"emulieren" scheint), zeigen tc_SPUpper und tc_SPLower nicht auf den
Stack des gestarteten Programmes, sondern auf den des aufrufenden
CLI-Prozesses (daher ergeben sich die "magischen" 3200 bytes, die auch
in pr_Stacksize stehen).

Ein einigermaßen sicherer Weg dürfte es sein, zu schauen, ob der
tatsächliche Stackpointer (also z.B. die Adresse einer auto-Variablen)
zwischen tc_SPUpper und tc_SPLower liegt und dann entsprechend deren
Differenz als Stackgröße zu benutzen, ansonsten cli_Defaultstack.

Ich hoffe, ich habe jetzt nicht wieder alles durcheinandergeworfen,
man sollte ja eigentlich nicht vor dem Aufstehen posten ;-)

Georg

--
Georg Saßen, Düsseldorf, Germany. Voice +49 211 255799, Fax +49 211 255798

Andreas M. Kirchwitz

unread,
Jan 8, 1993, 4:59:53 AM1/8/93
to
In article <4059.07...@bluemoon.GUN.de>, Georg Sassen writes:

> >Mit "(long)task->tc_SPUpper-(long)task->tc_SPLower" geht's. Warum?
>
> Mit APTR darf man nicht rechnen, siehe exec/types.h:

Schluchz... C ist eine unfreundliche Sprache...
(haette ja wenigstens eine Warning bzw. ein Error kommen koennen,
so wie sie/er auch kommt, wenn man versucht, mit "void *" zu rechnen)

> Der obige Weg zur Erkennung der Stackgröße funktioniert nur unter
> Betriebssystemversionen >=2.0 und mit der Commodore-Shell. Unter 1.3,

Das >=2.0 ist okay ;-)

> aber auch mit der WShell 2.0 (die auch unter >=2.0 einen 1.3 CLI zu
> "emulieren" scheint), zeigen tc_SPUpper und tc_SPLower nicht auf den
> Stack des gestarteten Programmes, sondern auf den des aufrufenden
> CLI-Prozesses (daher ergeben sich die "magischen" 3200 bytes, die auch
> in pr_Stacksize stehen).

Ich kenne mich mit den internen Dingen nicht soooo gut aus, aber wenn
die WShell das so "abenteuerlich" setzt, woher weiss denn da das ge-
startete Programm, wo sein "zugeteilter" Stack liegt bzw. wann genau
sein Stack ueberlaeuft? Das blosse Vorhandensein eines Stackpointers
sagt ja noch nicht viel ueber die Groesse des Stacks aus. Und auch
nicht, wieviel vom Stack bereits "verbraucht" ist.

> Ein einigermaßen sicherer Weg dürfte es sein, zu schauen, ob der
> tatsächliche Stackpointer (also z.B. die Adresse einer auto-Variablen)
> zwischen tc_SPUpper und tc_SPLower liegt und dann entsprechend deren
> Differenz als Stackgröße zu benutzen, ansonsten cli_Defaultstack.

Wie kommt man denn als "Aussenstehender" an die Adresse einer Auto-
Variablen in einem fremden Programm?

Kein einfacher Weg?... Andreas

Henning Schmiedehausen

unread,
Jan 7, 1993, 8:31:46 PM1/7/93
to

Pointer Arithmetik.

task->tc_SPUpper - task->tc_SPLower ist ein

APTR - APTR

oder auch ein

(void *) - (void *)

also ist die Differenz die Anzahl der void Elemente zwischen tc_SPUpper und
tc_SPLower.

Also habe ich mal ein kleines Test-Programm geschrieben:

- snip -

#include <stdio.h>

#include <exec/types.h>

TYPE *foo,*bar;

long test[4];

main()
{
foo = (TYPE *)&test[0];
bar = (TYPE *)&test[2];

printf("bar - foo= %d\n", bar - foo);
printf("(LONG)bar - (LONG)foo= %d\n", (LONG)bar - (LONG)foo);

}

- snap -

| pointer | LONG |
---------------------------------+---------+------+-
sc LINK DEFINE TYPE=void test.c | 4 | 8 |
sc LINK DEFINE TYPE=char test.c | 8 | 8 |
sc LINK DEFINE TYPE=int test.c | 2 | 8 |
sc LING DEFINE TYPE=long test.c | 2 | 8 |
sc LINK DEFINE TYPE=short test.c | 4 | 8 |

(Die Adreß-Differenz zwischen zwei Langwörtern ist nunmal acht.

An sich sollte ja gelten:

( pnt2 - pnt1 ) * sizeof (typ auf den pnt1/pnt2 zeigen) = (ULONG)pnt1 - (ULONG)pnt2

Das ist auch richtig für

( pnt2 - pnt1 ) * sizeof (char / int / long / short) =

(char * - char * ) * 1 = 8 -> stimmt
(int * - int * ) * 4 = 8 -> stimmt
(long * - long * ) * 4 = 8 -> stimmt
(short * - short * ) * 2 = 8 -> stimmt
(void * - void * ) * 0 = ????

(sizeof(void) ist 0!)

Laut K&R, 2nd Edition gilt:

Wenn zwei Zeiger auf Objekte vom gleichen Typ subtrahiert werden, ist das
Resultat ein Integer-Wert mit Vorzeichen, der den Abstand zwischen den
Objekten repräsentiert, auf die die Zeiger zeigen; Zeiger auf
aufeinanderfolgende Objekte unterscheiden sich um 1. Der Resultattyp ist
implementierungsabhängig, aber er ist als ptrdiff_t in der Definitionsdatei
<stddef.h> (long int bei SAS 6.1) vereinbart.

Hmmm.. also ich weiß nicht, wie ich die Differenz zweier Zeiger auf void
Objekte betrachten soll. Ich habe zwar im K&R nichts gefunden, aber IMHO
sollte man mit (void *) Subtraktionen vorsichtig sein.

Demnach würde ich für Dich:

(UBYTE *)task->tc_SPUpper - (UBYTE *)task->tc_SPLower

vorschlagen, dabei sollte das richtige Ergebnis rauskommen.

Ansonsten poste ich jetzt was nach adsp.sas und frage nach dem Ergebnis bei
(void *) - (void *)

Mach' Dir nix draus. Du bist nicht der erste, der mit Pointer-Arithmetik
reingefallen ist, und wirst nicht der letzte sein. Ich erinnere mich an AKBP
II, das ist unser Kernal Hacking Kurs, als wir mit den Betriebssystem Gurus
fast zwei Tage lang einen Fehler suchten und er sich letztlich in sowas fand:

struct foo
{
char *daten;
};

struct foo *pointer;

pointer = (struct foo *) malloc( sizeof(struct foo) + datenbereich);
pointer->daten = pointer + sizeof(struct foo);

Jetzt darf jeder mal raten, die Lösung kommt nach dem ^L

pointer->daten = pointer + 1;


( Ja, hartmut. C ist halt eine Hackersprache. Alle, die das nicht abkönnen,
oder solche Fehler nicht auf Anhieb sehen, sollen Oberon oder Modula (würg)
verwenden. Und solche Fehler finde ich inzwischen auch, wenn Du mich um
10:00 in der Nacht weckst und an den Rechner setzt... ;)

Alloooooooha!
Henning


--
\\ _ Henning Schmiedehausen - bar...@forge.franken.de _ // Amiga -
\X/ --- Home of Barnard's Software Forge - ECG038 --- \X/ Learning to Fly

Hole Dir die Super Pluckyo Bros. fuer Deinen Debilo Spielcomputer! Nerve
Deine Eltern solange, bis sie Dir das Zeugs kaufen. Fuer nur 879$ und 99
cents. Batterie, Spielanleitung und Joystick kosten extra!
- The Super Pluckyo Bros. - K-ACME TV

Michael van Elst

unread,
Jan 8, 1993, 4:39:15 PM1/8/93
to
In <F+hgs*n...@zikzak.in-berlin.de> a...@zikzak.in-berlin.de (Andreas M. Kirchwitz) writes:
>Wie kommt man denn als "Aussenstehender" an die Adresse einer Auto-
>Variablen in einem fremden Programm?

Das ist (ungefaehr aber aussreichend genau) identisch mit dem Wert des
Stackpointers. Und der steht in der Task-Struktur.

Salut,
--
Michael van Elst
UUCP: universe!local-cluster!milky-way!sol!earth!uunet!unido!mpirbn!p554mve
Internet: p55...@mpirbn.mpifr-bonn.mpg.de
"A potential Snark may lurk in every tree."

Gerald Malitz

unread,
Jan 8, 1993, 3:32:45 PM1/8/93
to

Weil Du Dir die Definition von APTR nicht angeschaut hast :^)

| typedef void *APTR; /* 32-bit untyped pointer */

Zwei Pointer auf void kannst Du nicht subtrahieren, denn wie gross
ist sizeof(void)? Der gcc nimmt dafuer 1 an, SAS/C scheinbar 2...

Tschuess, Gerald.

--
// Gerald Malitz, Bolchentwete 4, 3300 Braunschweig, Voice: +49 531 796832
\X/ g...@germal.escape.de Quo vadis, Deutschland?

Henning Schmiedehausen

unread,
Jan 9, 1993, 8:04:12 PM1/9/93
to
In article <F+hgs*n...@zikzak.in-berlin.de>, Andreas M. Kirchwitz writes:

> In article <4059.07...@bluemoon.GUN.de>, Georg Sassen writes:
>
> > >Mit "(long)task->tc_SPUpper-(long)task->tc_SPLower" geht's. Warum?
> >
> > Mit APTR darf man nicht rechnen, siehe exec/types.h:
>
> Schluchz... C ist eine unfreundliche Sprache...
> (haette ja wenigstens eine Warning bzw. ein Error kommen koennen,
> so wie sie/er auch kommt, wenn man versucht, mit "void *" zu rechnen)

Hier muß ich mal dem hartmut absolut recht geben:

Wenn man mit einer Programmiersprache nicht zurecht kommt, oder von ihren
Feinheiten erschlagen wird, dann sollte man sie nicht benutzen.

Also: Kirchwitz, Sie benutzen in Zukunft Modula oder Oberon. Da passiert
sowas nicht. :)

Alloooooooha!
Henning


--
\\ _ Henning Schmiedehausen - bar...@forge.franken.de _ // Amiga -
\X/ --- Home of Barnard's Software Forge - ECG038 --- \X/ Learning to Fly

Have no joy, have no fun; I have PacMan - but no SUN

Henning Schmiedehausen

unread,
Jan 9, 1993, 8:05:48 PM1/9/93
to
In article <Zfrgs*Y...@germal.escape.de>, Gerald Malitz writes:

> Zwei Pointer auf void kannst Du nicht subtrahieren, denn wie gross
> ist sizeof(void)? Der gcc nimmt dafuer 1 an, SAS/C scheinbar 2...

Nein, sinnigerweise ist sizeof(void) 0. Nur die Differenz zweier
aufeinanderfolgender void pointer ist 2... =:)

Andreas M. Kirchwitz

unread,
Jan 8, 1993, 10:13:55 PM1/8/93
to
In article <1993Jan8.2...@mpifr-bonn.mpg.de>, Michael van Elst writes:

> >Wie kommt man denn als "Aussenstehender" an die Adresse einer Auto-
> >Variablen in einem fremden Programm?
>
> Das ist (ungefaehr aber aussreichend genau) identisch mit dem Wert des
> Stackpointers. Und der steht in der Task-Struktur.

Juheeee, es funktioniert !! *schmatz*

Young Indiana Bonzo -- Raiders of the lost Stack

Georg Sassen

unread,
Jan 9, 1993, 5:41:57 AM1/9/93
to
In article <F+hgs*n...@zikzak.in-berlin.de> a...@zikzak.in-berlin.de (Andreas M. Kirchwitz) writes:

>Ich kenne mich mit den internen Dingen nicht soooo gut aus, aber wenn
>die WShell das so "abenteuerlich" setzt, woher weiss denn da das ge-
>startete Programm, wo sein "zugeteilter" Stack liegt bzw. wann genau
>sein Stack ueberlaeuft? Das blosse Vorhandensein eines Stackpointers
>sagt ja noch nicht viel ueber die Groesse des Stacks aus. Und auch
>nicht, wieviel vom Stack bereits "verbraucht" ist.

Eine Möglichkeit dazu wäre, im Startupcode des Programms gleich zu
Anfang den aktuellen Stackpointer (der ja noch recht "unverbraucht"
ist) einer Variablen zuzuweisen und diese dann später ggfs. mit dem
aktuellen Stackpointer zu vergleichen. Das sollte einigermaßen genau
sein. Wie groß der zugeteilte Stack eines Programmes tatsächlich ist,
steht angeblich (laut Guru-Buch S.388) im ersten Longword über dem
anfänglichen Stackpointer. Inwieweit das allerdings stimmt bzw.
dokumentiert ist, habe ich nicht verifiziert, vielleicht möchte sich
ja Ralph dazu auslassen?

hartmut Goebel

unread,
Jan 10, 1993, 11:50:04 AM1/10/93
to
In article <skQgs*B...@forge.franken.de>, Henning Schmiedehausen writes:

>In article <F+hgs*n...@zikzak.in-berlin.de>, Andreas M. Kirchwitz writes:

>> Schluchz... C ist eine unfreundliche Sprache...
>> (haette ja wenigstens eine Warning bzw. ein Error kommen koennen,
>> so wie sie/er auch kommt, wenn man versucht, mit "void *" zu rechnen)

Das stimmt. Wenn nichtmal eines dieser Warnings (die ich persönlich
auch für idiotisch halte) kommt, gehört der Compiler in die Tonne.

>Hier muß ich mal dem hartmut absolut recht geben:
>
>Wenn man mit einer Programmiersprache nicht zurecht kommt, oder von ihren
>Feinheiten erschlagen wird, dann sollte man sie nicht benutzen.

Jetzt schieb mir mal nicht so einen Spruch unter!

Meine Worte sind immernoch:

Eine Sprache, die sowas zulaesst ist eine Gefahr (alles andere waere
zu wenige stark). Denn sie hilft offensichtlich nicht Fehler zu
vermeiden, obwohl es kein Problem wäre (vom Standpunkt der
Compilertechnik).

>Also: Kirchwitz, Sie benutzen in Zukunft Modula oder Oberon. Da passiert
>sowas nicht. :)

Soll ich die "welcome to the club"-mail schon fertig machen,
Andreas?

> \\ _ Henning Schmiedehausen - bar...@forge.franken.de _ // Amiga -

+++hartmut

| Hartmut Goebel | UseNet: har...@oberon.nbg.sub.org |
| Amiga Software | Z-Netz: HAR...@ASN.ZER // Only Amiga |
| Manufactur | Fido: 2:246/81.1 IRC: Essich \X/ Oberon ZOC |

Michael van Elst

unread,
Jan 10, 1993, 12:27:55 PM1/10/93
to
In <38xgs*4...@zikzak.in-berlin.de> a...@zikzak.in-berlin.de (Andreas M. Kirchwitz) writes:
>Juheeee, es funktioniert !! *schmatz*

Buuaeeeeeeh, ein Hund hat mich gekuesst. Holt Jod, heisses Wasser.....
ich bin vergiftet !!

S.P.Zeidler

unread,
Jan 10, 1993, 3:23:37 PM1/10/93
to
In <38xgs*4...@zikzak.in-berlin.de> a...@zikzak.in-berlin.de (Andreas M. Kirchwitz) writes:
>In article <1993Jan8.2...@mpifr-bonn.mpg.de>, Michael van Elst writes:
>>[ .. Stackpointers..]

>Juheeee, es funktioniert !! *schmatz*

Heee, das ist meiner !

>Young Indiana Bonzo -- Raiders of the lost Stack

Wuff :-)

MfG,
spz
PS: .. Indiana ? wir nannten den HUND Indiana !

Andreas M. Kirchwitz

unread,
Jan 11, 1993, 6:01:12 AM1/11/93
to
In article <skQgs*B...@forge.franken.de>, Henning Schmiedehausen writes:

> > > Mit APTR darf man nicht rechnen, siehe exec/types.h:
>

> Wenn man mit einer Programmiersprache nicht zurecht kommt, oder von ihren
> Feinheiten erschlagen wird, dann sollte man sie nicht benutzen.

Die Zeit arbeitet fuer MICH. Mal sehen, wann es C nach ANSI-2 Standard
gibt ;-) Da muss man dann alles (Funktionen, Strukturen) explizit
includen, hehe...

Und natuerlich compilieren ANSI-2 C-Compiler nur BEWIESENE Programme :)


"If it's not loud, it doesn't work!"
-- Blank Reg, from "Max Headroom"

Joerg-Cyril Hoehle

unread,
Jan 11, 1993, 3:44:23 PM1/11/93
to
Georg Sassen (ge...@bluemoon.GUN.de) wrote:

: Wie groß der zugeteilte Stack eines Programmes tatsächlich ist,


: steht angeblich (laut Guru-Buch S.388) im ersten Longword über dem
: anfänglichen Stackpointer. Inwieweit das allerdings stimmt bzw.

Jaaaa! Da habe ich die richtige Größe auch immer gefunden, egal ob
1.3/CBM, 1.3/ARP oder 2.0, WorkBench oder nicht. Schön, daß diese
Möglichkeit auch von jemand anderem als mir mal erwähnt wird,
cli_DefaultStack ist nicht zuverlässig.

(in C) *(long *)(pr->pr_ReturnAddress) oder wie auch immer das Feld
heißt, eventuell mal 4.

: dokumentiert ist, habe ich nicht verifiziert, vielleicht möchte sich
: ja Ralph dazu auslassen?

Würde ich auch gerne wissen. Wer garantiert, daß die Shell die
Stackgröße auf den Stack legt bzw. wo steht geschrieben, daß die Shell
dies tun muß?

Tschüß,
Joerg.
hoe...@inf-wiss.ivp.uni-konstanz.d

Michael van Elst

unread,
Jan 12, 1993, 7:54:39 AM1/12/93
to
In <cb2hs*5...@oberon.nbg.sub.org> har...@oberon.nbg.sub.org (hartmut Goebel) writes:
>Eine Sprache, die sowas zulaesst ist eine Gefahr (alles andere waere
>zu wenige stark). Denn sie hilft offensichtlich nicht Fehler zu
>vermeiden, obwohl es kein Problem wäre (vom Standpunkt der
>Compilertechnik).

Da vergisst man leicht, das Programmierer Menschen sind und ein bisschen
der Physchologie beduerfen. Deswegen:

Je mehr Fehler eine Sprache findet, desto eher wird sich der Programmierer
auf den Compiler verlassen und uebersieht dabei die Fehler, die der Compiler
nicht findet.

MfG,

Andreas M. Kirchwitz

unread,
Jan 12, 1993, 8:47:30 AM1/12/93
to
In <cb2hs*5...@oberon.nbg.sub.org> har...@oberon.nbg.sub.org (hartmut Goebel) writes:

> >Also: Kirchwitz, Sie benutzen in Zukunft Modula oder Oberon. Da passiert
> >sowas nicht. :)
>
>Soll ich die "welcome to the club"-mail schon fertig machen,
>Andreas?

Oberon is nich. Da gefaellt es mir nicht so, dass man anscheinend
vor jede Struktur bzw. jede Funktion schreiben muss, woher man sie
importiert hat. Kann man das irgendwie umgehen? (ich habe von
Oberon nicht viel Ahnung)

Dafuer bin ich leidenschaftlicher Modula-2-Programmierer :-)

Fuer groessere Sachen niemals C, hehe... Andreas

Andreas M. Kirchwitz

unread,
Jan 12, 1993, 10:41:49 AM1/12/93
to

>Da vergisst man leicht, das Programmierer Menschen sind und ein bisschen
>der Physchologie beduerfen. Deswegen:

Eben drum...

>Je mehr Fehler eine Sprache findet, desto eher wird sich der Programmierer
>auf den Compiler verlassen und uebersieht dabei die Fehler, die der Compiler
>nicht findet.

Das kann ich nicht unbedingt nachvollziehen.
(waere ja auch zu schoen, wenn wir einer Meinung waeren :-)))))))

Ein "strenger" Compiler (bzw. eine "strenge" Sprache) zwingt den
Programmierer, relativ sauber zu programmieren, damit er nicht mit
Errors/Warnings zugemuellt wird (behindert naemlich den Arbeitsfluss).
Man gewoehnt sich also einen recht sauberen Programmierstil an.
(einfach schon durch das hoehe Niveau des Compilers bzw. der Sprache)

Ein "lascher" Compiler (bzw. Sprache) erlaubt dem Programmierer zu
pfuschen. Das tut er automatisch. Selbstdisziplin hilft da gar
nichts. Das Programmieren soll halt schnell gehen... und so wird
der Programmierer stets immer nur so gut programmieren, wie es der
Compiler (oder die Sprache) von ihm verlangt.

Logische Fehler haben ja i.d.R. mit dem Compiler nix zu tun. Die
macht man so oder so -- egal ob nun "sauber" programmiert oder nicht.
Ich moechte mal DEN sehen, der IMMER weiss, ob die For-Next-Schleife
nun bei "i<max" oder "i<=max" aufhoeren soll :-) Dem Compiler isses
schnuppe.

Unter Modula-2 (M2Amiga) meckert der Compiler sofort, wenn ich
Pointer falsch caste. Denn wer hat schon immer alle Includes im
Kopf, dass er es auf Anhieb richtig macht? Mein SAS/C ist da
recht lachs. Der stoert sich nicht mal, wenn ich APTR und BPTR
durcheinanderbringe... M2Amiga wandelt die z.B. automatisch um!
(sowas wie BADDR oder MKBADDR benoetigt man praktisch nicht :-)

Gerade BPTR sind doch eine Sache, die der Compiler ruhig vor dem
Programmierer "verbergen" kann. Normalerweise ist es doch voellig
unwichtig, was fuer ein Pointer das ist (solange der Compiler es
weiss). Ich erwarte von einem guten Compiler wenigstens eine Warning.
Die Zeiten von "Du-hast-es-so-gewollt-da-hast-Du-es" sind vorbei.

Ich weiss leider nicht, ob mit "Strict ANSI" der SAS/C bessere
Erros/Warnings ausgibt. Die C= Includes machen damit bekanntlich
Probleme... ich will also SAS/C da lieber nix unterstellen.
Wollte nur generell beschreiben, was mich manchmal an C bzw.
SAS/C nervt...

Tschoe, Andreas

Lars Duening

unread,
Jan 12, 1993, 5:11:00 PM1/12/93
to
a...@opal.cs.tu-berlin.de (Andreas M. Kirchwitz) schreibt in
<1993Jan12.1...@cs.tu-berlin.de>:

> [einiges zutreffendes ueber Programmfehler, -stil, und Compiler]
> ...


> Ich erwarte von einem guten Compiler wenigstens eine Warning.
> Die Zeiten von "Du-hast-es-so-gewollt-da-hast-Du-es" sind vorbei.

Leider wurden dabei die Zeiten des geradlinigen "Ich-will-es-so-
also-halt-die-Klappe" meist gleich mit beendet...

...z.B. 'ptr := SYSTEM.ADR(ptr^[1]);' statt 'INC(ptr);' ...

Lars schuettelts.
--
Lars Duening; due...@ibr.cs.tu-bs.de

Michael van Elst

unread,
Jan 12, 1993, 7:50:53 PM1/12/93
to
In <1993Jan12.1...@cs.tu-berlin.de> a...@opal.cs.tu-berlin.de (Andreas M. Kirchwitz) writes:
>Man gewoehnt sich also einen recht sauberen Programmierstil an.

Ein sauberer Programmierstil erzeugt noch keine fehlerfreien Programme,
nicht mal naeherungsweise.

>Ein "lascher" Compiler (bzw. Sprache) erlaubt dem Programmierer zu
>pfuschen. Das tut er automatisch. Selbstdisziplin hilft da gar
>nichts. Das Programmieren soll halt schnell gehen... und so wird
>der Programmierer stets immer nur so gut programmieren, wie es der
>Compiler (oder die Sprache) von ihm verlangt.

Stimmt nicht, da der Compiler 'dumm' ist, muss der Programmierer
besser aufpassen. Er uebersieht daher auch weniger Fehler, die der
Compiler (egal fuer welche Sprache) nie finden wuerde.

Das Pentagon hat vor ein paar Jahren mal Code ueberprueft. Programme in
"strengen" Sprachen wiesen dabei mehr Fehler auf, als Programme in
laschen Sprachen. Erst bei der Verwendung von Assembler stieg die
mittlere Fehlerzahl wieder an.

Kann natuerlich sein, dass sich die Programmierer inzwischen angepasst
haben.

>Logische Fehler haben ja i.d.R. mit dem Compiler nix zu tun. Die
>macht man so oder so -- egal ob nun "sauber" programmiert oder nicht.

Was heisst denn "sauber" ?

>Unter Modula-2 (M2Amiga) meckert der Compiler sofort, wenn ich
>Pointer falsch caste.

In Modula _castet_ man pointer ????

>Denn wer hat schon immer alle Includes im
>Kopf, dass er es auf Anhieb richtig macht? Mein SAS/C ist da
>recht lachs. Der stoert sich nicht mal, wenn ich APTR und BPTR
>durcheinanderbringe... M2Amiga wandelt die z.B. automatisch um!
>(sowas wie BADDR oder MKBADDR benoetigt man praktisch nicht :-)

Was natuerlich Fehler produzieren kann, wenn die Werte mal nicht
konvertiert werden. In C steht das dann _explizit_ da.

>Gerade BPTR sind doch eine Sache, die der Compiler ruhig vor dem
>Programmierer "verbergen" kann. Normalerweise ist es doch voellig

Njet. So einen Kludge moechte ich nicht verborgen wissen.

>unwichtig, was fuer ein Pointer das ist (solange der Compiler es
>weiss). Ich erwarte von einem guten Compiler wenigstens eine Warning.
>Die Zeiten von "Du-hast-es-so-gewollt-da-hast-Du-es" sind vorbei.

Letzters hat IMHO was mit "unsauberer" Programmierung zu tun, ist
aber unabhaengig von der Sprache. Und in C ist ein "DhesgdhDe"
auch wieder _explizit_ mit einem Sprachkonstrukt verbunden
(z.B. cast).

Man sollte halt seine eigenen Programme auch lesen. Write-Only sourcen
sind was fuer 'coder'.

Salut,

Andreas Hofbauer

unread,
Jan 13, 1993, 12:18:55 AM1/13/93
to

Es geht viel besser und einfacher mit folgendem code-fragment:

int get_stacksize()
{
struct Task *t;
t = FindTask(NULL);
return t->tc_SPUpper - t->tc_SPLower;
}

--
_
--(_)
| | Andreas Hofbauer, Software Engineer
|bsc| bueroautomation (ECG001)
---

hartmut Goebel

unread,
Jan 14, 1993, 10:10:35 AM1/14/93
to
In article <1993Jan12....@mpifr-bonn.mpg.de>, Michael van Elst writes:

>Je mehr Fehler eine Sprache findet, desto eher wird sich der Programmierer
>auf den Compiler verlassen und uebersieht dabei die Fehler, die der Compiler
>nicht findet.

Je mehr Fehler der Compiler findet, umso mehr Zeit hat der
Programmierer, sich um die zu kümmern, die der nicht findet.

Wenn ich mir vorstelle, ich müsste auch noch die finden, die der
Compiler schon entdeckt, dann gut Nacht. Da ginge nichts mehr (ausser
mir die Lust, aber ver- :-)

>Michael van Elst

hartmut Goebel

unread,
Jan 14, 1993, 10:13:22 AM1/14/93
to
In article <1993Jan12.1...@cs.tu-berlin.de>, Andreas M. Kirchwitz writes:

>Oberon is nich. Da gefaellt es mir nicht so, dass man anscheinend
>vor jede Struktur bzw. jede Funktion schreiben muss, woher man sie
>importiert hat. Kann man das irgendwie umgehen? (ich habe von
>Oberon nicht viel Ahnung)

Nein, das läßt sich nicht umgehen. Aber die für Modulnamen lassen
sich beim IMPORT abkürzungen angeben (wie bei ISO-Modula), also
IMPORT mm := MeinModulMitLangemNamen; ... mm.MeineProc();

Wenn das das einzige ist, das Dich stört, solltest Du mal ein Projekt
in Oberon durchziehen (oder ein Buch lesen, hat bei eime Freund
Wunder bewirkt :-). Ich sagen nur Record-extension, persistente Typen
(leider nicht bei Amiga Oberon :-( Up-calls (und überhaupt das ganze
OOP-Zeug). Goil!

>Dafuer bin ich leidenschaftlicher Modula-2-Programmierer :-)

Ist ja schon eine gute Basis. War ich früher auch :-)
BTW: Warum hast Du eigentlich noch nie was auf AMOK veröffentlicht?

> Fuer groessere Sachen niemals C, hehe... Andreas

+++hartmut

hartmut Goebel

unread,
Jan 14, 1993, 10:24:05 AM1/14/93
to
In article <1993Jan12....@ibr.cs.tu-bs.de>, Lars Duening writes:

>Leider wurden dabei die Zeiten des geradlinigen "Ich-will-es-so-
>also-halt-die-Klappe" meist gleich mit beendet...

Ich versteh zwar nicht ganz, was das mit dem "IwesahdK" zu tun hat, aber...

>...z.B. 'ptr := SYSTEM.ADR(ptr^[1]);' statt 'INC(ptr);' ...

Fällt Dir der Unterschied nicht auf?

Im ersten Fall steht riesig da, daß es unsauber ist und die
komplizierte Schreibweise macht diese Konstruktion ätzend.

Im zweiten Fall erhöhst Du den Pointer, aber um wieviel, und wozu
eigentlich? Mit Pointer kann man nicht rechnen, das sind keine
Zahlen, auch wenn es Zahlenwerte sind.

Überhaupt ist das ganze Zeiger gerechen schwachsinn und scheidert in
dem Moment, in dem ich einen GarbaceCollector verwenden möchte.

>Lars Duening; due...@ibr.cs.tu-bs.de

hartmut Goebel

unread,
Jan 14, 1993, 10:30:58 AM1/14/93
to
In article <1993Jan13.0...@mpifr-bonn.mpg.de>, Michael van Elst writes:

>In <1993Jan12.1...@cs.tu-berlin.de> a...@opal.cs.tu-berlin.de (Andreas M. Kirchwitz) writes:

>Stimmt nicht, da der Compiler 'dumm' ist, muss der Programmierer
>besser aufpassen. Er uebersieht daher auch weniger Fehler, die der
>Compiler (egal fuer welche Sprache) nie finden wuerde.

Ein dummer Compiler halst dem Programmierer die Arbeit auf, Dinge zu
überprüfen, die er (der Compiler) selbst wesendlich besser prüfen
kann. Der Programmierer muss besser aufpassen, damit er wenigstens
die Feher findet, die der Compiler finden koennte. (Wir reden ja
nicht über logische Fehler. Die kann kein Compiler finden. Aber ich
wiederhole micht :-)

>Das Pentagon hat vor ein paar Jahren mal Code ueberprueft. Programme in

Das Pentagon hat schon allerlei Untersuchungen gemacht. Ob man denen
glaubt, ist Ansichtssache.

>Kann natuerlich sein, dass sich die Programmierer inzwischen angepasst
>haben.

An was???

>Was heisst denn "sauber" ?

Syntaktisch und (soweit compiler-prüfbar) semantisch Korrekt.

>In Modula _castet_ man pointer ????

In Modula muss das t.Z. sein. in Oberon nicht mehr :-) Ich sag nur
Record-Extensions.

>Letzters hat IMHO was mit "unsauberer" Programmierung zu tun, ist
>aber unabhaengig von der Sprache. Und in C ist ein "DhesgdhDe"
>auch wieder _explizit_ mit einem Sprachkonstrukt verbunden
>(z.B. cast).

In seltenen Fällen. Beim Linken in falsche Reihenfolge nützt auch ein
cast nicht mehr. Und an dieser Schwachstelle aller C-Compiler läst
sich nciht rütteln.

>Michael van Elst

Harry Schittler

unread,
Jan 14, 1993, 5:53:23 AM1/14/93
to
In article <1993Jan12.1...@cs.tu-berlin.de> a...@opal.cs.tu-berlin.de (Andreas M. Kirchwitz) writes:
> Oberon is nich. Da gefaellt es mir nicht so, dass man anscheinend
> vor jede Struktur bzw. jede Funktion schreiben muss, woher man sie
> importiert hat. Kann man das irgendwie umgehen? (ich habe von
> Oberon nicht viel Ahnung)
Eija, wenn du MathIEEEDoubTrans importieren willst, waere es schon ein
bischen laestig, wenn man beim Import des Modules keinen Bezeichner
vereinbaren koennte.
zb.
IMPORT m:MathIEEEDoubTrans;
und dann
Winkel:=m.Sin(PI);
Statt
Winkel:=MathIEEEDoubTrans.Sin(PI)
Ich glaub man gewoehnt sich dran, und ausserdem weiss mann spaeter zufort
in welchem Module die Procedure zu finden ist

cu Harry
--
Harry Schittler / Arndtstr. 2 / 6200 Wiesbaden / ro...@indi.rmt.sub.org

Georg Sassen

unread,
Jan 14, 1993, 5:06:32 AM1/14/93
to
In article <andi...@bsc.adsp.sub.org> an...@bsc.adsp.sub.org (Andreas Hofbauer) writes:

>Es geht viel besser und einfacher mit folgendem code-fragment:
>
>int get_stacksize()
> {
> struct Task *t;
> t = FindTask(NULL);
> return t->tc_SPUpper - t->tc_SPLower;
> }

Genau darum, daß dies nicht immer funktioniert, ging doch die
Diskussion ;-)
Unter AmigaOS <=1.3 bzw. mit WShell auch unter >=2.0 erhältst Du damit
die Stackgröße des CLI-Prozesses (also irgendwas um die 3200 bytes)
und nicht die Stackgröße des von diesem gestarteten Programms.

Andreas Hofbauer

unread,
Jan 15, 1993, 12:50:04 AM1/15/93
to
In article <4452.14...@bluemoon.GUN.de> ge...@bluemoon.GUN.de (Georg Sassen) writes:
> In article <andi...@bsc.adsp.sub.org> an...@bsc.adsp.sub.org (Andreas Hofbauer) writes:
>
> >Es geht viel besser und einfacher mit folgendem code-fragment:
> >
> >int get_stacksize()
> > {
> > struct Task *t;
> > t = FindTask(NULL);
> > return t->tc_SPUpper - t->tc_SPLower;
> > }
>
> Genau darum, daß dies nicht immer funktioniert, ging doch die
> Diskussion ;-)
> Unter AmigaOS <=1.3 bzw. mit WShell auch unter >=2.0 erhältst Du damit
> die Stackgröße des CLI-Prozesses (also irgendwas um die 3200 bytes)
> und nicht die Stackgröße des von diesem gestarteten Programms.

Sorry, ich hab den Anfang der Diskussion wohl verpennt :-).

Dennoch, hab ich jetzt mal in der AmigaMail nachgeschaut. Bryce Nesbitt
schreibt da zum Thema "How to Find the Stack Size at Run Time" folgendes
"C"-Beispiel (leicht veraendert):

...

process = FindTask(NULL);
if (cli = (struct CommandLineInterface *)(process->pr_CLI<<2))
{ // from CLI
stack = (cli->cli_DefaultStack << 2);
}
else
{ // from Workbench
stack = process->pr_StackSize;
}

...

Ausserdem erwaehnt auch er dass die stack-groesse aus dem cli auf dem
stack-top liegt.

S.P.Zeidler

unread,
Jan 15, 1993, 5:13:07 PM1/15/93
to
In <1993Jan12.1...@cs.tu-berlin.de> a...@opal.cs.tu-berlin.de (Andreas M. Kirchwitz) writes:
>Ein "lascher" Compiler (bzw. Sprache) erlaubt dem Programmierer zu
>pfuschen. Das tut er automatisch. Selbstdisziplin hilft da gar
>nichts. Das Programmieren soll halt schnell gehen... und so wird
>der Programmierer stets immer nur so gut programmieren, wie es der
>Compiler (oder die Sprache) von ihm verlangt.

Nur solange das Programm dann hinterher auch noch funktioniert.
Und speziell bei Pointerfehlern unter C fliegt einem dann die
ganze Chose mehr oder weniger spektakulaer um die Ohren ...
Die Selektion auf Bugs findet da halt nicht beim Uebersetzen sondern
beim Testen statt. Welches dafuer auch entsprechend sorgfaeltig
zu erfolgen hat.

gcc -pedantic -Wall is it :-)

MfG,
spz

Michael van Elst

unread,
Jan 16, 1993, 5:54:34 PM1/16/93
to
In <2plis*c...@oberon.nbg.sub.org> har...@oberon.nbg.sub.org (hartmut Goebel) writes:
>In seltenen Fällen. Beim Linken in falsche Reihenfolge nützt auch ein
>cast nicht mehr. Und an dieser Schwachstelle aller C-Compiler läst
>sich nciht rütteln.

Ich hab noch keinen C Compiler gesehen der Linken wuerde. Das einzige
Problem, das bei einigen Linkern (nicht Compilern und unabhaengig von
der Sprache) auftritt existiert bei Libraries, die aus Effizienzgruenden
nur einmal durchsucht werden.

Ralph Babel

unread,
Jan 17, 1993, 1:53:42 AM1/17/93
to
hartmut Goebel schrieb in <Bilis*b...@oberon.nbg.sub.org>:

> Mit Pointer kann man nicht rechnen,

Ein bißchen Niklaus-Wirth-geschädigt, wie? Die Äquivalenz
von Zeigern und Feldbezeichnern ist eine der nützlichsten
Eigenschaften von C und C++.

Ralph

hartmut Goebel

unread,
Jan 17, 1993, 8:01:46 AM1/17/93
to
In article <1993Jan16.2...@mpifr-bonn.mpg.de>, Michael van Elst writes:

>Ich hab noch keinen C Compiler gesehen der Linken wuerde. Das einzige
>Problem, das bei einigen Linkern (nicht Compilern und unabhaengig von
>der Sprache) auftritt existiert bei Libraries, die aus Effizienzgruenden
>nur einmal durchsucht werden.

Nein, das Problem ist, daß C-Compiler keine _eindeutigen_ Namen
erzeugen. Das hat die Folge, daß die Linkreihenfolge entscheidet, ob
die Prozedure MyBlafasel aus dem Modul (wie nennst sich das bei C?
Gibt's nicht, wah?) MyBla oder MYFasel kommt.

Und für so was ist eindeutig der Compiler zuständig.

Würde der Linker mosern: Label defined twice (oder so), könnte man
keine Compiler-LinkLib zusammen mit der amiga.lib verwenden, weil
beide sprinft enthalten.

hartmut Goebel

unread,
Jan 17, 1993, 8:05:49 AM1/17/93
to
In article <1993Jan15.2...@mpifr-bonn.mpg.de>, S.P.Zeidler writes:

>Nur solange das Programm dann hinterher auch noch funktioniert.
>Und speziell bei Pointerfehlern unter C fliegt einem dann die
>ganze Chose mehr oder weniger spektakulaer um die Ohren ...
>Die Selektion auf Bugs findet da halt nicht beim Uebersetzen sondern
>beim Testen statt. Welches dafuer auch entsprechend sorgfaeltig
>zu erfolgen hat.

Jaja, das modernt Software Engeniering *schuttel*
So macht man das also: ständig wieder neu Linken, nur weil der
Compiler nicht in der Lage ist, _einfchste_ Fehler zur Compilerzeit
zu finden.

Stimmt schon. wenn einem die Maschie ordentlich um die Ohren fliegt,
merkt man halt besser, daß was falsch ist.
BAber was, wenn sie ausnahmswiese _nicht_ fliegt?

>MfG,
> spz

Runter kommen sie alle

Lothar Maier

unread,
Jan 17, 1993, 2:10:48 PM1/17/93
to

...und mit Mungwall findet man dann auch die daraus entstehenden
Fehler, zumindest einige ;-)...

...und wie sollen die armen C'ler auch sonst einen VARIABLE
übergeben...

> Ralph

--
..L. Maier Silcherstr. 1 7910 Neu-Ulm Voice:0731 86391..

hartmut Goebel

unread,
Jan 18, 1993, 3:12:28 PM1/18/93
to

#define nützlich gefährlich
dann hast Du recht.

Das ständige Arbeiten mit Zeigern (incl. Rechnen mit denen), macht
die Programme absolut unsicher. Fehler die dadurch auftreten, werden
z.T. _nie_ gefunden.
Wie willst Du denn bitte eine RangeCheck machen, wenn Du nicht mit
Indices arbeitets, sondern immer einen Zeiger verschiebst? Wie willst
Du dann Speichermanagement machen (ohne daß sich der Programmierer
damit rumschlagen muß, also eine GarbeCollector oder so)?

Usw, usf. Weitere Kritikpunkte findet man z.B. in dem Artikel 'C++? C
critic', auf den ich schon hingewiesen habe. Besonders interessant
finde ich Kap. 2 und Kap. 6.

>Ralph

Martin J. Laubach

unread,
Jan 18, 1993, 9:03:58 AM1/18/93
to
In article <Bilis*b...@oberon.nbg.sub.org>, hartmut Goebel writes:

| Mit Pointer kann man nicht rechnen

Aja, ich wusste ja, dass ich die letzten paar Jahre etwas grundsaetzlich
falsch gemacht habe...

mjl


--
"CDTV is selling like warm pie" -- J.P. at Kanton in FFM.

Lars Duening

unread,
Jan 18, 1993, 9:41:50 AM1/18/93
to
In <y8lis*a...@oberon.nbg.sub.org> schreibt Hartmut Goebel:

> Ich sagen nur Record-extension, persistente Typen

^^^^^^^^^^^^^^^^^
Hoi, was ist denn das nun schon wieder?
> (leider nicht bei Amiga Oberon :-( Up-calls (und ueberhaupt das ganze
> OOP-Zeug). Goil!
Jaa, kann man sich richtig dran gewoehnen...

Lars
--
Lars Duening; due...@ibr.cs.tu-bs.de

Lars Duening

unread,
Jan 18, 1993, 10:24:40 AM1/18/93
to
In <Bilis*b...@oberon.nbg.sub.org> anwortet Hartmut Goebel:

> In article <1993Jan12....@ibr.cs.tu-bs.de>, Lars Duening writes:
>
> >Leider wurden dabei die Zeiten des geradlinigen "Ich-will-es-so-
> >also-halt-die-Klappe" meist gleich mit beendet...
>
> Ich versteh zwar nicht ganz, was das mit dem "IwesahdK" zu tun hat, aber...
>
> >...z.B. 'ptr := SYSTEM.ADR(ptr^[1]);' statt 'INC(ptr);' ...
>

> Faellt Dir der Unterschied nicht auf?
>
> Im ersten Fall steht riesig da, dass es unsauber ist und die
> komplizierte Schreibweise macht diese Konstruktion aetzend.

Mag sein, dass es im Sinne des Spracherfinders 'unsauber' ist, aber ab
und zu lassen sich solche Konstrukte entweder gar nicht vermeiden,
oder bieten Effizienzvorteile. Und dann sag ich dem Compiler lieber
einmal "Dieses Programm sieht zwar unsauber aus, ist aber wirklich so
gemeint.", als dass ich durch n-maliges Neueintippen der aetzenden
Konstruktion die Anzahl der Tippfehler erhoehe (wieso hat Oberon
eigentlich keinen Preprozessor?).
IMHO ist das INC() verstaendlicher als der .ADR()-Ausdruck.

> Im zweiten Fall erhoehst Du den Pointer, aber um wieviel, und wozu
> eigentlich?

Das 'um wieviel' hab ich mal C-like als den Pointer-Basistyp angenommen, und
das wozu sollte klar sein: ich will das Datenelement nach dem aktuell
addressierten als naechstes ueber diesen Zeiger erreichen (da mein
Oberon-2 noch nicht komplett ist, konnte ich die 'Zeiger auf offene
Arrays' noch nicht ausprobieren).

> Mit Pointer kann man nicht rechnen, das sind keine Zahlen, auch wenn
> es Zahlenwerte sind.

Seit wann kann man nur mit Zahlen rechnen? Es ist doch nur eine Frage
der Definition der Rechenoperatoren. 'string + string' ist auch kein
arithmetischer Ausdruck, aber dennoch sinnvoll.

> Ueberhaupt ist das ganze Zeiger gerechen schwachsinn
Noe.
> und scheidert in dem Moment, in dem ich einen GarbageCollector
> verwenden moechte.

Wieso? Der GC kann sich ja auf die beschraenken, mit denen ich nicht
rechne (Amiga-Oberon 3 hat ja extra die UNTRACED POINTER eingefuehrt,
da nicht alles vom GC ueberwacht werden kann).

Eine Option a la (* $Sloppy+ *) waere ja schon ausreichend.
Ich finde es halt nur nicht gut, dass vor lauter
Highlevel-OOP-Abgehobenheit die Lowlevel-Programmierung unnoetig
schwer gemacht wird (und umgekehrt).

Martin J. Laubach

unread,
Jan 19, 1993, 10:04:14 AM1/19/93
to
| Nein, das Problem ist, daß C-Compiler keine _eindeutigen_ Namen
| erzeugen. Das hat die Folge, daß die Linkreihenfolge entscheidet, ob
| die Prozedure MyBlafasel aus dem Modul MyBla oder MYFasel kommt.

Das ist allerdings ein Feature. Wie oft hab ich schon Libraryfunktionen
durch optimierte Versionen ersetzt...

Michael van Elst

unread,
Jan 19, 1993, 2:06:33 PM1/19/93
to
In <avijs*k...@oberon.nbg.sub.org> har...@oberon.nbg.sub.org (hartmut Goebel) writes:
>Nein, das Problem ist, daß C-Compiler keine _eindeutigen_ Namen
>erzeugen. Das hat die Folge, daß die Linkreihenfolge entscheidet, ob
>die Prozedure MyBlafasel aus dem Modul (wie nennst sich das bei C?
>Gibt's nicht, wah?) MyBla oder MYFasel kommt.

Oh, der Compiler erzeugt schon eindeutige Namen. Nur gibt es halt
kein Sprachkonstrukt Modul, bei dem man die Qualifizierung des Namens
abkuerzen koennte. Setz die Prefixes selbst davor und schon hast Du
keine Probleme (C Programmierer haben die sowieso nicht).

MfG,

Michael van Elst

unread,
Jan 19, 1993, 2:09:17 PM1/19/93
to
In <Zyijs*l...@oberon.nbg.sub.org> har...@oberon.nbg.sub.org (hartmut Goebel) writes:
>BAber was, wenn sie ausnahmswiese _nicht_ fliegt?

Dann haette der Modula oder Oberon-Compiler mit 90%-ger Wahscheinlichkeit
halt auch nicht gemeckert :)

Wie gesagt, die Fehler, die eine strenge Sprache findet gehoeren zu den
einfachen, die ein aufmerksamer Programmierer findet.

Franz-Josef Reichert

unread,
Jan 20, 1993, 10:58:46 AM1/20/93
to
In article <lo....@silch.ulm.sub.org>, Lothar Maier writes:

> In article <63...@babylon.rmt.sub.org> rba...@babylon.rmt.sub.org (Ralph Babel) writes:
> > hartmut Goebel schrieb in <Bilis*b...@oberon.nbg.sub.org>:
> >
> > > Mit Pointer kann man nicht rechnen,
> >
> > Ein bißchen Niklaus-Wirth-geschädigt, wie? Die Äquivalenz
> > von Zeigern und Feldbezeichnern ist eine der nützlichsten
> > Eigenschaften von C und C++.
>
> ...und mit Mungwall findet man dann auch die daraus entstehenden
> Fehler, zumindest einige ;-)...
>
> ...und wie sollen die armen C'ler auch sonst einen VARIABLE
> übergeben...

Nicht so schüchtern! Den Gedanken ruhig zu Ende
führen und demnächst als Ergebnis verkünden, daß selbst das Rechnen
mit Feldindizes viel zu gefährlich sei, da ja kein Compiler per
definitionem die Grenzen eines dynamisch instantiierten Objektes
kennen kann.

Was soll überhaupt indirekte Feldindizierung? Ein
Index hat eine Konstante zu sein, und sonst gar nichts! Teufelszeug,
gefährliches das, hinwech damit...

> ..L. Maier Silcherstr. 1 7910 Neu-Ulm Voice:0731 86391..

--
Best regards,
Franz-Josef Reichert GERMANY - VOICE: +49 6805 7417
Kuchlingerstrasse 13 UUCP: fjrei@kbsaar.{saar|adsp}.sub.org
6601 Kleinblittersdorf fj...@kbsaar.saar.de

Kai 'wusel' Siering

unread,
Jan 20, 1993, 12:13:42 AM1/20/93
to
In article <avijs*k...@oberon.nbg.sub.org>, hartmut Goebel writes:

% In article <1993Jan16.2...@mpifr-bonn.mpg.de>, Michael van Elst writes:
%
% >Ich hab noch keinen C Compiler gesehen der Linken wuerde. Das einzige
% >Problem, das bei einigen Linkern (nicht Compilern und unabhaengig von
% >der Sprache) auftritt existiert bei Libraries, die aus Effizienzgruenden
% >nur einmal durchsucht werden.
%
% Nein, das Problem ist, daß C-Compiler keine _eindeutigen_ Namen
% erzeugen. Das hat die Folge, daß die Linkreihenfolge entscheidet, ob
% die Prozedure MyBlafasel aus dem Modul (wie nennst sich das bei C?
% Gibt's nicht, wah?) MyBla oder MYFasel kommt.
%
% Und für so was ist eindeutig der Compiler zuständig.

Ein Moduln-Compiler vielleicht ... C kennt nun einmal keine solche
Unterscheidung -- soll Dein Compiler dann was erfinden? Ich empfinde das
eigentlich nicht als Nach- sondern als Vorteil -- noch sehe ich einen
sonderlich großen Sinn darin, in jedem Modul eine Funktion bla() zu
schreiben. Wenn a.bla was anderes als b.bla macht, sollte das imho auch
aus dem Namen hervorgehen (z. B. AllocMem() & MyAllocMem()) ... Ist aber
wohl auch Gewohnheit =:->

% Würde der Linker mosern: Label defined twice (oder so), könnte man
% keine Compiler-LinkLib zusammen mit der amiga.lib verwenden, weil
% beide sprinft enthalten.

Wer zuerst kommt, malt zuerst. Imho sollte ein Linker optional
meckern können -- könnte ja auch ein Versehen sein =:->
kai

-- _
_ // Kai 'wusel' Siering, Villa Straylight, Hamburg, Germany. Go for MIME!
\X/: <wu...@hactar.hanse.de> Exile: <wu...@wolfhh.hanse.de> iso-8859-1: äöüß

"Kennst Du dieses Lied? Hört genau zu: `Hmm hmm, himmmm'. Na?"
-- Al, "Eine schrecklich nette Familie"

hartmut Goebel

unread,
Jan 20, 1993, 7:21:06 PM1/20/93
to
In article <1993Jan18.1...@ibr.cs.tu-bs.de>, Lars Duening writes:

>In <y8lis*a...@oberon.nbg.sub.org> schreibt Hartmut Goebel:
>
>> Ich sagen nur Record-extension, persistente Typen
> ^^^^^^^^^^^^^^^^^
>Hoi, was ist denn das nun schon wieder?

Verzeihung, persistende Objekte.

Das sind Objekte, die auch dann noch existieren, wenn das Programm,
das sie erzeugt hat nicht mehr läuft. In der Regel werden die sich
halt in einer Datei wiederfinden :-)

Der Gag daran ist, daß hierbei wirklich mit gespeichert wird, welchen
dynamischen Typ das Object hatte, auch wenn man eine Superclass
handlet.

>Lars Duening; due...@ibr.cs.tu-bs.de

hartmut Goebel

unread,
Jan 21, 1993, 8:00:49 AM1/21/93
to
In article <lo....@silch.ulm.sub.org>, Lothar Maier writes:

>...und mit Mungwall findet man dann auch die daraus entstehenden
>Fehler, zumindest einige ;-)...

Aber nur die Sonderfälle "Grenze des allozierten Speichers wird
überschritten". Un das sind oft wirklich ausnahmen.

>...und wie sollen die armen C'ler auch sonst einen VARIABLE
>übergeben...

&s und *s sind doch genug. Darfste nur nicht vergessen :-)

>..L. Maier Silcherstr. 1 7910 Neu-Ulm Voice:0731 86391..

+++hartmut

hartmut Goebel

unread,
Jan 21, 1993, 8:02:51 AM1/21/93
to
In article <1993Jan18.1...@ibr.cs.tu-bs.de>, Lars Duening writes:

[es geht darum, ob man Pointer einfach incrementieren kann]

>Mag sein, dass es im Sinne des Spracherfinders 'unsauber' ist, aber ab
>und zu lassen sich solche Konstrukte entweder gar nicht vermeiden,
>oder bieten Effizienzvorteile. Und dann sag ich dem Compiler lieber

Mir sind eigentlich keine Fälle bewußt, in denen solche Konstruke
wirklich unvermeidlich wären. Und die Effizienzsteigerung ist ein zu
schwaches Argument: besser ein korrektes Programmes als
eines, das nur auf Effizens getrimm ist und vor Fehlern (gefundene
und nicht gefundene) strotzt.

>einmal "Dieses Programm sieht zwar unsauber aus, ist aber wirklich so
>gemeint.", als dass ich durch n-maliges Neueintippen der aetzenden
>Konstruktion die Anzahl der Tippfehler erhoehe (wieso hat Oberon

Um das einem Modula-2 oder Oberon[-2] Compiler zu sagen, mußt Du hat
etwas Aufwand treiben. Schließlich soll es einfacher sein, saubere
Programme zu schreiben, als Hacks.

Das mit dem Vertippen ist Schwachsinn. Das findet der Compiler ohne
Probleme und wozu hat man den Tastaturmakros, wenn man das schon
verwenden will?

>eigentlich keinen Preprozessor?).

Weiß isch nicht mehr genau, aber es war ein gutes Argument. Frag hat
mal in comp.lang.modula nach.

>IMHO ist das INC() verstaendlicher als der .ADR()-Ausdruck.

IMHO nicht. Zumal der SYSTEM.ADR()-Ausdruck deutlich mahct, daß es
sich um eine systemabhängige Sache handelt.

>addressierten als naechstes ueber diesen Zeiger erreichen (da mein
>Oberon-2 noch nicht komplett ist, konnte ich die 'Zeiger auf offene

??? soll das einer verstehen?
Schreibst Du einen eigenen Compiler, oder was, oder wie?

AmigaOberon 3.0 unterstützt das jedenfalls.

>der Definition der Rechenoperatoren. 'string + string' ist auch kein
>arithmetischer Ausdruck, aber dennoch sinnvoll.

INC(prt) ist aber ein arithmetischre Ausdruck, das ist der
Unterschied. Oder wasrum denkst Du wohl, ist INC(char) nicht möglich?

>Wieso? Der GC kann sich ja auf die beschraenken, mit denen ich nicht
>rechne (Amiga-Oberon 3 hat ja extra die UNTRACED POINTER eingefuehrt,
>da nicht alles vom GC ueberwacht werden kann).

Wobei die UNTRACED POINTERS eine eiweiterung von AO sind, die nur
mit der norwendigkeit begründet ist, daß halt nicht alle Objekte von
Oberon erzeugt werden (z.B. Fenster). Ansonsten ist UNTRACED _nicht_
standard. (Wenn Du jattz anfangen willst, über Oberon Standard oder
nicht zu diskutieren, dann wende Dich erstmal an
G_DO...@ame.zer.sub.org -- Nein, das sollte keine Flame sein!)

>Eine Option a la (* $Sloppy+ *) waere ja schon ausreichend.

Und was soll die machen? Und wie willst Du solche Programme dann auf
anderen Rechenern kompilieren?

>Ich finde es halt nur nicht gut, dass vor lauter
>Highlevel-OOP-Abgehobenheit die Lowlevel-Programmierung unnoetig
>schwer gemacht wird (und umgekehrt).

Es wird nicht schwer gemacht. Schau in das Buch "Project Oberon",
dort wird das ganz Oberon-System entwickelt und erklärt. Das, was Du
low-level nennst, findet man dort nicht (oder nut kaum, ich hab das
Buch nicht auswednig gelernt :-)

hartmut Goebel

unread,
Jan 21, 1993, 8:18:04 AM1/21/93
to
In article <1993Jan19.1...@email.tuwien.ac.at>, Martin J. Laubach writes:

> Das ist allerdings ein Feature. Wie oft hab ich schon Libraryfunktionen
>durch optimierte Versionen ersetzt...

Und wie oft bist Du schon daruaf reingefallen? Und wieviele Anfragen
gibt es jährlich in den Netzen (nicht hier, sondern in denen, in
denen auch Anfänger schreiben) warum dieses und jenes nicht mehr
funkt, wobei die Lösung "falsche Linkreihenfolge" heißt?

Der Nutzten, einzelen Routinen auszutauschen, ohne auch nur ein Modul
(es hat mi noch immer keiner gesagt, wie das in 'C' heißt) neu zu
compilieren, ist viel zu gering gegenüber der Fehlerträchtigkeit.

> mjl

hartmut Goebel

unread,
Jan 21, 1993, 8:22:45 AM1/21/93
to
In article <1993Jan19.1...@mpifr-bonn.mpg.de>, Michael van Elst writes:

>Oh, der Compiler erzeugt schon eindeutige Namen. Nur gibt es halt

Eindeutig innerhalb des Moduls. Alles andere ist eine C-Compiler
egal. Halt kein Scope-Konzept.

>kein Sprachkonstrukt Modul, bei dem man die Qualifizierung des Namens
>abkuerzen koennte. Setz die Prefixes selbst davor und schon hast Du
>keine Probleme

Kalr, das Programmieren muß sich arbeit machen, nur weil der Compiler
zu faul, zu dumm, zu was-weiß-ich-alles ist, um das selbst zu machen.
Da ist das mit den nicht eindeutigen NAmen ja nur ein Bleistift.

>(C Programmierer haben die sowieso nicht).

OpusDei-Jünger haben auch keine Probleme mit der täglichen Selbst-
geiselung :-\

hartmut Goebel

unread,
Jan 21, 1993, 8:26:35 AM1/21/93
to
In article <1993Jan19.1...@mpifr-bonn.mpg.de>, Michael van Elst writes:

>Dann haette der Modula oder Oberon-Compiler mit 90%-ger Wahscheinlichkeit
>halt auch nicht gemeckert :)

Doch. Weil genau dazu gibt es die Laufzeit-Umgebung. (Bevor weider
eine meckert: die kann man für die releases auch abschalten).

Und die fängt die Fehler ab, bevor einem die Kiste um die Ohren
fliegt und Daten zerstört werden (oder die Datenübertragenung
unterbrochen, oder, oder, oder). Und eben auch viele Fehler, bei
denen einem die Kiste nicht um die Ohren fliegen würde und die lange
unentdeckt bleiben könnten.

>Wie gesagt, die Fehler, die eine strenge Sprache findet gehoeren zu den
>einfachen, die ein aufmerksamer Programmierer findet.

Und wenn der Programmierer mal eine schlechen Tag hat und nicht
aufmerksam ist? Der Compiler ist immer gleich gut (oder schlecht)
drauf. Einen Fehler, den er heute findet, findet er auch morgen und
übermorgen und wenn siche der Programmierer besoffen hat, immer
noch.

Warum wollt ihr dem Progger eigentlich eine Arbeit aufhasen, die ein
Compiler viel besser erledigen kann? Braucht ihr den Rausch der
Freiheit? Ich dachte, ich wollt gute Software entwickeln? Warum Zeit
verscwenden mit etwas, was sie Maschne wirklich besser kann. Da geh
ich doch lieber mit Fruenden weg, als solche Fehler zu suchen.

>Michael van Elst

Kai 'wusel' Siering

unread,
Jan 21, 1993, 11:04:37 PM1/21/93
to
In article <s6Dks*t...@oberon.nbg.sub.org>, hartmut Goebel writes:

% In article <1993Jan19.1...@email.tuwien.ac.at>, Martin J. Laubach writes:
%
% > Das ist allerdings ein Feature. Wie oft hab ich schon Libraryfunktionen
% >durch optimierte Versionen ersetzt...
[...]
% Der Nutzten, einzelen Routinen auszutauschen, ohne auch nur ein Modul
% (es hat mi noch immer keiner gesagt, wie das in 'C' heißt) neu zu

Guck' halt in c.s.a.programmers nach *in den Hinterhalt lock* =:->

% compilieren, ist viel zu gering gegenüber der Fehlerträchtigkeit.

Bah! Wenn ich absolut tödlich lahme strcpy()-Funktion ersetzen will
durch meine optim(ale|ierte), was soll ich dann tun? Im Programm jeweils
my.strcpy() verwenden? Oder Austausch/Erweiterung der c.lib, z. B. um
Pipes (oder was zu stopfendes =:->) dazu zu bringen, mit normalen
Funktionen angesprochen werden zu können oder das Pattern-Matching schon
im Startup-Code (vor main()) zu machen oder ...

»C« ist so, wie es ist -- und so ist es gut; stoppt die Müslifizierung!
kai

-- _
_ // Kai 'wusel' Siering, Villa Straylight, Hamburg, Germany. Go for MIME!
\X/: <wu...@hactar.hanse.de> Exile: <wu...@wolfhh.hanse.de> iso-8859-1: äöüß

"Ich liebe es, wenn netter Besuch reinschaut!"
-- Sledge Hammer, "Sledge Hammer - The early years"

Michael van Elst

unread,
Jan 22, 1993, 5:05:22 AM1/22/93
to
In <YUJjs*n...@oberon.nbg.sub.org> har...@oberon.nbg.sub.org (hartmut Goebel) writes:
>Wie willst Du denn bitte eine RangeCheck machen, wenn Du nicht mit
>Indices arbeitets, sondern immer einen Zeiger verschiebst? Wie willst
>Du dann Speichermanagement machen (ohne daß sich der Programmierer
>damit rumschlagen muß, also eine GarbeCollector oder so)?

Vielleicht sollte sich der Programmier gerade damit rumschlagen ? Elegante
Programme nach dem Motto "eine Loesung existiert" bringen schliesslich nicht
viel.

"Garbage Collector" ist eine schwache Entschuldingung fuer faule Programmierer
und laesst sich bei LISP und BASIC noch gerade vertreten.

Michael van Elst

unread,
Jan 22, 1993, 5:09:52 AM1/22/93
to
In <s6Dks*t...@oberon.nbg.sub.org> har...@oberon.nbg.sub.org (hartmut Goebel) writes:
>gibt es jährlich in den Netzen (nicht hier, sondern in denen, in
>denen auch Anfänger schreiben) warum dieses und jenes nicht mehr
>funkt, wobei die Lösung "falsche Linkreihenfolge" heißt?

Also, ich kenne keine einzige solche Anfrage. Selbst unsere
Programmieranfaenger vergessen nur Libraries.

Salut,

Michael van Elst

unread,
Jan 22, 1993, 5:16:10 AM1/22/93
to
In <reDks*v...@oberon.nbg.sub.org> har...@oberon.nbg.sub.org (hartmut Goebel) writes:
> >Wie gesagt, die Fehler, die eine strenge Sprache findet gehoeren zu den
> >einfachen, die ein aufmerksamer Programmierer findet.

>Und wenn der Programmierer mal eine schlechen Tag hat und nicht
>aufmerksam ist? Der Compiler ist immer gleich gut (oder schlecht)
>drauf. Einen Fehler, den er heute findet, findet er auch morgen und
>übermorgen und wenn siche der Programmierer besoffen hat, immer
>noch.

Lies nochmal. Die Fehler, die der Compiler findet gehoeren zu den
_einfachen_. MaW, ob die auf Anhieb gefunden werden ist relativ uninteressant.
Schliesslich mus man in jedem Fall das Programm _testen_ um die komplizierten
Fehler zu finden.

>Warum wollt ihr dem Progger eigentlich eine Arbeit aufhasen, die ein
>Compiler viel besser erledigen kann? Braucht ihr den Rausch der
>Freiheit?

Das werfe ich immer den Assembler-Programmieren vor :)

Ich halse nicht auf. Ich sorge dafuer, dass der obige besoffene
Programmierer mit schlechtem Tag und so gar nicht in die Verlegenheit
kommt, sich auf den Compiler verlassen zu wollen.

>Ich dachte, ich wollt gute Software entwickeln? Warum Zeit
>verscwenden mit etwas, was sie Maschne wirklich besser kann. Da geh
>ich doch lieber mit Fruenden weg, als solche Fehler zu suchen.

Die Verwendung von Oberon garantiert keine fehlerfreien Programme.

Salut,

Martin J. Laubach

unread,
Jan 22, 1993, 8:51:37 AM1/22/93
to
|> Und wie oft bist Du schon daruaf reingefallen?

Haelt sich, ehrlich gesagt, in Grenzen. Zumindest nicht oefter, als
ich in Modula irgendwas aus dem falschen Modul importiert hab.

Koennen wir das bloede meine-Sprache-ist-besser-als-deine-Sprache
jetzt vielleicht endlich ad acta legen? Erstens bringt es nix, und
zweitens ist es nervtoetend.

Angela Schmidt

unread,
Jan 22, 1993, 10:23:02 AM1/22/93
to
In article <YUJjs*n...@oberon.nbg.sub.org>, har...@oberon.nbg.sub.org (hartmut Goebel) writes:
> >hartmut Goebel schrieb in <Bilis*b...@oberon.nbg.sub.org>:
> >> Mit Pointer kann man nicht rechnen,

Oh - das wäre furchtbar, wenn _das_ wirklich so wäre! Dann müsste ich
mich ja auf Assembler-Ebene hinabbegeben *schüttel*.

> Das ständige Arbeiten mit Zeigern (incl. Rechnen mit denen), macht
> die Programme absolut unsicher. Fehler die dadurch auftreten, werden
> z.T. _nie_ gefunden.

Ach so, jetzt weiß ich endlich, warum das Amiga-Betriebssystem
immer noch nicht fehlerfrei ist. Schließlich wurde es ja größtenteils
in C programmiert - kein Wunder... Warum nur hat Commodore uns
das wieder angetan - hätten sie gleich Modula oder Oberon benutzt,
dann wäre jetzt alles viiieeel besser!

> Wie willst Du denn bitte eine RangeCheck machen, wenn Du nicht mit
> Indices arbeitets, sondern immer einen Zeiger verschiebst?

Ein Range-Check macht Programme notgedrungen langsamer, obwohl
man ihn in vielen Fällen gar nicht braucht. Und wenn es mal wirklich
auf die Geschwindigkeit ankommt, bist Du mit C oder C++ immer
besser bedient. Und selbst wenn Du aus Geschwindigkeitsgründen
den Range-Check ausschaltest, kannst Du es nach meinen Informationen
immer nur für alle Variablen in einem bestimmten Source-Fetzen tun.
Und das ist dann bei komplexeren Gebilden (zumindest nach Deiner
Definition) wieder zu gefährlich.

Ach ja, ganz nebenbei bemerkt: Du kannst Dir in C++ eine Klasse
definieren, die einen Range-Check durchführt. So kannst Du dann
die "gefährlichen" Variablen von den "ungefährlichen" trennen.
Dann nämlich entscheidet der Variablentyp, ob gecheckt wird oder
nicht.

> Wie willst
> Du dann Speichermanagement machen (ohne daß sich der Programmierer
> damit rumschlagen muß, also eine GarbeCollector oder so)?

Häh? Sprichst Du von Routinen wie malloc()? Das ist doch kein Problem.
Auch wenn man wegen fehlender MEMF-Flags die Library-Routinen nicht
benutzen will, kann man sich jederzeit so etwas selber schreiben
oder die Library-Sourcen entsprechend modifizieren. Oder war das
eher eine Anspielung auf den furchtbar langsamen
Lisp-Garbage-Collector?

C ist halt für erfahrene Programmierer gedacht, nicht für Anfänger!


V v
@/@@=\ Ein absoluter C-Fan,
00 &=- Angela
oOoO_/` \\_
\ /&\ Angela Schmidt cand. inf. (Nessy@IRC) | Amiga //
|>O<| EMail: Ang...@rz.uni-karlsruhe.de | 1000 //
/ \_/\/\/v, Weekend: +49 731 712316 (9am-9pm) | \\ // since
/___________\ Weekdays: 721 6904263 (10am-11pm) | \X/ 1986

hartmut Goebel

unread,
Jan 22, 1993, 11:09:12 AM1/22/93
to
In article <20019...@hactar.uucp>, Kai 'wusel' Siering writes:

> Ein Moduln-Compiler vielleicht ... C kennt nun einmal keine solche
>Unterscheidung --

Davon rede ich ja die ganze Zeit: Das Grundkonzept von 'C' ist
offensichtlich nicht für solche Dinge gedacht. Und damit für mittlere
und große Projecte nicht gut (um nicht zu sagen schlecht :-)
geeignet.

>soll Dein Compiler dann was erfinden? Ich empfinde das

Nichts erfinden, einfach _intern_ den Modulnamen davorhängen. Aber
das scheidert, wie Du aj schon schreibst, am fehlende Modul-Konzept
von C.

>eigentlich nicht als Nach- sondern als Vorteil -- noch sehe ich einen
>sonderlich großen Sinn darin, in jedem Modul eine Funktion bla() zu
>schreiben.

Es gibt Fälle, in denen das sehr sinnvoll ist. Besonders bei
Datenabstraktion. Z.B. wenn man die implementation einer Liste anders
machen will. In Beiden Modulen werden die gleichen Prozeduren
angeboten und beide halten sich an die gleichen Invarianten etc. Für
das importierende Modul ist es dann völlig egal, wie die Liste intern
aufgebaut ist, solange der Rest stimmt.

>Wenn a.bla was anderes als b.bla macht, sollte das imho auch

Ja, -Wenn_ es etwas anders macht.

>aus dem Namen hervorgehen (z. B. AllocMem() & MyAllocMem()) ... Ist aber
>wohl auch Gewohnheit =:->

Würde ich das auch im oben Beschiebenen Fall tun, könnte ich die
Wartbarkeit das Program schon mal um 50% kürzen :-(

Und nochmal das alte Beispiel von sprintf: gibt's in der amiga.lib
und in der Compiler lib. In beiden Fällen ist der Name gleich, die
Funktionalität nicht (amiga.lib.sprinft kann kein %f). Da Kann der
Benutzer gar nicht machen: wenn er aus versehen fallsch linkt, fällt
er auf die Schnauze. Und diese Fehler können lang unentdeckt bleiben.
Z.B. wenn der Programmteil nicht mehr neu getestet wird, weil es
schon wurde. (Oder testest Du nach jedem Linken _alle_ Programmteile
neu? Ich nicht.)

> Wer zuerst kommt, malt zuerst. Imho sollte ein Linker optional
>meckern können -- könnte ja auch ein Versehen sein =:->

Nicht optional. Das ist eindeutig ein Fehler, auf dem der Benutzer
hingewiesen werden _muß_. Alles andere sind falsche Sicherheits-
versprechen.

> kai

Ralph Babel

unread,
Jan 22, 1993, 11:11:00 PM1/22/93
to
hartmut Goebel schrieb in <YUJjs*n...@oberon.nbg.sub.org>:

> Das ständige Arbeiten mit Zeigern (incl. Rechnen mit
> denen), macht die Programme absolut unsicher.

Dies zu beweisen wird Dir schwerfallen.

> Wie willst Du denn bitte eine RangeCheck machen,

Wer sagt denn, daß ich das machen _will_? _Du_ magst mit
einer faschistoiden Programmiersprache, die Dir vorschreibt,
wie die Implementation eines Algorithmus auszusehen hat,
glücklich werden - _ich_ brauche keinen Compiler, "der mich
am Patschehändchen sicher durch die böse Welt führt".

> Wie willst Du dann Speichermanagement machen (ohne daß
> sich der Programmierer damit rumschlagen muß, also eine
> GarbeCollector oder so)?

Garbage Collection kann nicht Aufgabe eines
High-Level-Assemblers sein.

> Usw, usf.

Eine etwas dünne Argumentationsbasis. Wäre Dir C++ wirklich
geläufig, so wüßtest Du, daß Deine Kommentare zum angeblich
nicht vorhandenen Modulkonzept, zu Referenztypen (gegen die
sich VAR-Parameter etwas dürftig ausnehmen) und zur
Bereichsüberprüfung völlig ins Leere gehen.

Ralph

hartmut Goebel

unread,
Jan 23, 1993, 6:53:09 AM1/23/93
to
In article <6nkks*v...@kbsaar.saar.de>, Franz-Josef Reichert writes:

> Nicht so schüchtern! Den Gedanken ruhig zu Ende
>führen und demnächst als Ergebnis verkünden, daß selbst das Rechnen
>mit Feldindizes viel zu gefährlich sei, da ja kein Compiler per
>definitionem die Grenzen eines dynamisch instantiierten Objektes
>kennen kann.

Das kann zwar nicht der Compiler, aber die Laufzeitumgebung! Die ist
genau für solche Checks da. Und in Oberon-2 geht das auch mit dynamischen Objekten.

> Was soll überhaupt indirekte Feldindizierung? Ein

Schade, bisher war die Dikussion eigentlich recht Sachlich. Warum
Deine Polemik? Fühlst Du dich erwa persönlich angegriffen, nur weil
wir Die von Dir verwendete Programmiersprache kritisieren? Bing duch
lieber ein gutes Argument für C.

>Franz-Josef Reichert GERMANY - VOICE: +49 6805 7417

+++hartmut

hartmut Goebel

unread,
Jan 23, 1993, 7:01:40 AM1/23/93
to
In article <1993Jan22.1...@mpifr-bonn.mpg.de>, Michael van Elst writes:

>Vielleicht sollte sich der Programmier gerade damit rumschlagen ? Elegante

Warum soll sich derProgrammierer mir Resource-Tracking rumschlagen,
wenn das der Computer besser kann?

>"Garbage Collector" ist eine schwache Entschuldingung fuer faule Programmierer
>und laesst sich bei LISP und BASIC noch gerade vertreten.

Anscheinend ist Dein Bild von einem GC von eben diesen beiden
Sparchen geprägt. Schon mal daran gedacht, daß es auch andere
Möglichkeiten geben könnte, einen GC zu implementieren?

Z.B. als eizenen Hintergrund-Task? Das hat auch den Vorzteil, daß das
Programm weiterlaufen kann, wärend der GC den Speicher frei gibt. Das
geht allemal schneller, als wenn das Programm das selbst mahct.

>Michael van Elst

hartmut Goebel

unread,
Jan 23, 1993, 7:04:59 AM1/23/93