back2roots/padua/padua.7z/padua/text/TagItems

Internet Message Format | 2014-05-19 | 23KB

From de.comp.sys.amiga.misc Tue Jun 23 17:07:08 1992
Newsgroups: de.comp.sys.amiga.misc
Path: cs.tu-berlin.de!math.fu-berlin.de!pbinfo2!billy
From: [e-mail] (Michael Boehnisch)
Subject: Re: TagItems und C-Compiler
Message-ID: <[e-mail]>
Organization: Uni-GH Paderborn
References: <5pcer*[e-mail]>
Date: Tue, 23 Jun 1992 09:26:32 GMT

[e-mail] (Andreas M. Kirchwitz) writes:
:[line eater was here]
:
:     void meine_kleine_prozedur(void) {
:     {
:       ULONG tags[] = {RT_WaitPointer,TRUE,TAG_END};
:       if (rtGetStringA(str,len,title,NULL,(struct TagItem *)tags))
:
:       [...]
:     }
:
:
: Der Compiler (SAS/C) findet das toll.  Der Linker meint dazu jedoch:

Das entsetzt mich. Nicht Dein Quellcode, sondern dass der Compiler
nicht meckert... Damit Du weinger Probleme mit meinem Erklaeungs-
versuch hast, erst mal ein paar Begriffsbestimmungen (ja, wie in
der Vorlesung :-)

* Speicherklasse: C laesst als "Modifizierer" fuer Datentypen Angaben
  ueber die Verwaltung von Variablen zu. Als da waeren:

  - extern : Speicherplatz fuer die Variable/Funktion wird nicht hier,
    sondern in einem anderen Modul zur Verfuegung gestellt.

  - auto : Zulaessig nur fuer Variablendeklarationen innerhalb von
    Funktionen (ist da auch Voreinstellung). Speicherplatz wird zur
    Laufzeit des Programms auf dem Prozessor-Stack reserviert.
    Dies geschieht "automatisch" beim Betreten des fraglichen Blocks.

    Die Lebensdauer von Variablen dieser Speicherklasse reicht nur bis
    zum Verlassen des Blocks, danach sind sie "weg".

  - static : Hier gibt's zwei Bedeutungen, je nachdem wo die Deklaration
    steht (seufz)

    = ausserhalb einer Funktion : Das deklarierte Objekt ist nur inner-
      halb des aktuellen Moduls bekannt. Das erlaubt die mehrfache Ver-
      wendung von Namen in verschiedenen Modulen.

    = innerhalb einer Funktion : Das deklarierte Objekt wird nicht zur
      Laufzeit, sondern bereits zur Compilationszeit "statisch" erzeugt.
      Das erlaubt dem Compiler, diese Variablen vorzubesetzen, und ver-
      laengert die Lebensdauer der Variable ueber das Verlassen der
      Funktion hinaus. Das Objekt ist aber nur innerhalb des Blocks
      bekannt, indem es deklariert wurde.

  - register : Das Compiler versucht das Objekt wird in Registern des
    Prozessors unterzubringen, sofern moeglich. Beachte, dass Register
    keine Addresse haben. Programmstuecke wie:

    :
    register int x;
    :
    scanf("%d", &x);
    :

    zeigen ein voellig undefiniertes Verhalten.

Zurueck zu Deinem Problem - Wenn ich's recht in Erinnerung habe, geht
es so:

Initialisierung in der Deklaration von Variablen am Beginn eines
Blocks ist moeglich fuer:

   - "einfache" Variablen (also int, char, float, double...)

   - Variablen "komplexer" Datentypen (arrays, structs, ...)  NUR in
     der Speicherklasse "static".

"static" muss explizit angegeben werden, default ist "auto". Schreibe also

        :
        static ULONG tags[]....
        :

und Dein Code sollte korrekt uebersetzt und gelinkt werden. Die
Initialisierung erfolgt zur Compilationszeit und wird bei erneutem
Aufruf von "meine_kleine_prozedur()" nicht nochmal durchgefuehrt!

Statt dessen hast du in tags[] immer noch die Werte stehen, die beim
letzten Verlassen der Prozedur drin waren.

:     Warning! Absolute reference to UNKNOWN
:      module: rtsup.c        file: rtsup.o
:

Klar. Der Linker suchte ein Objekt zum initialisieren, dessen Speicher-
platz noch gar nicht bekannt sein kann. Aber warum erst der Linker das
bemerkt? Warten wir auf SAS/C 6.0 :-(

So, das war lang. Ich hoffe, ich konnte etwas Licht ins Dunkel
bringen...

Kalahari,
   Michael Boehnisch,
   [e-mail]

--

_________________________________________________________
*** Michael Boehnisch                                 ***
*** [e-mail]    I disclaim everything.  ***

From de.comp.sys.amiga.misc Wed Jul  1 14:19:28 1992
Path: cs.tu-berlin.de!zrz.tu-berlin.de!news.netmbx.de!Germany.EU.net!mcsun!uunet!think.com!sdd.hp.com!nigel.msen.com!spool.mu.edu!sol.ctr.columbia.edu!ira.uka.de!chx400!bernina!wild
From: [e-mail] (Markus Wild)
Newsgroups: de.comp.sys.amiga.misc
Subject: Re: TagItems und C-Compiler
Message-ID: <[e-mail]>
Date: 30 Jun 92 23:42:20 GMT
Article-I.D.: bernina.1992Jun30.234220.16956
References: <2Umfr*[e-mail]> <[e-mail]> <JcBgr*[e-mail]>
Sender: [e-mail] (USENET News System)
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
Lines: 51

In article <JcBgr*[e-mail]> [e-mail] (Andreas M. Kirchwitz) writes:
>#include <stdio.h>
>#include <stdlib.h>
>
>int main(int argc, char *argv[])
>{
>  char text[] = "Hello World\n";
>  printf("%s",text);
>  exit(10);
>}
>
>Optionen: <keine>
>Compiler: lc test.c
>Linker  : blink FROM LIB:cres.o test.o TO test LIB LIB:lc.lib SD SC ND
>
>    "Warning! Absolute reference to UNKNOWN" ...  Andreas

Hat vermutlich damit zu tun, dass SAS String-Konstanten grundlos in den
DATA Hunk wirft, und damit zu veraenderlichen Objekten erklaert. Wenn
die String-Konstante "Hello World\n" (und nicht etwa text!) im CODE Hunk
waere, haette BLink gar nix zu motzen, denn dann haette er keine data-text
Relokation auszufuehren, die ja in einem resident-faehigen Programm nicht
auftreten sollte.

>PPS: Kann man beim BLink eigentlich bestimmte Warnings (ausser mit "grep")
>     unterdruecken?

Groel.. BLink als Manifestation der AmigaDOS treuen Gemeinde, die sich
gern duselig quatscht auf der Kommandozeile (und daher Optionen ala -s -o
und dergleichen verdammt), wird mit einem Unix Programm (grep) zu
Leibe gerueckt, finde ich einfach koestlich ;-)

>PPPS: Interessante Effekte erhaelt man, wenn man 'printf("%s",text);'
>      durch 'printf(text);' ersetzt.  Eindrucksvoller Memory-Dump...
>      Anscheinend ist die Warning eine warnende Warning, der man doch
>      besser Beachtung schenken sollte.

Absolut unklar, weshalb das zu Problemen fuehren soll?! Die interne
Referent auf die String-Konstante ist doch in beiden Faellen 100%
gleich?  Im beiden Faellen sollte die Konstante als Source in einem
bcopy()/memmove() (oder inline kopiert) auf die Stack-Variable dienen,
der einzige Unterschied ist, dass im ersten Fall nach dem Push der
Stackadresse noch ein Push der Adresses des Format-Strings vorgeht, ent-
scheidet dies bei SAS ueber Crash oder nicht-Crash??

-Markus

--
Markus M. Wild    -  [e-mail]  |  [e-mail]
Vital papers will demonstrate their vitality by spontaneously moving
from where you left them to where you can't find them.

From de.comp.sys.amiga.misc Thu Jul  2 00:52:32 1992
Path: cs.tu-berlin.de!news.netmbx.de!Germany.EU.net!unido!sbsvax!coli-gate.coli.uni-sb.de!uhf!kbsaar!kbsaar!fjrei
From: [e-mail] (Franz-Josef Reichert)
Newsgroups: de.comp.sys.amiga.misc
Subject: Re: TagItems und C-Compiler
Message-ID: <TGlhr*[e-mail]>
Date: 1 Jul 92 11:40:39 GMT
References: <2Umfr*[e-mail]> <[e-mail]>
 <KlTgr*[e-mail]> <[e-mail]>
Reply-To: [e-mail] (Franz-Josef Reichert)
Organization: Private Amiga Site
Lines: 127
X-Newsreader: Arn V1.00 beta rel2

In article <[e-mail]>, Markus Wild writes:

> Jein... der Effekt ist gleich, nur muss ich im einen Fall ne giganteske
> Library (sprich amiga.lib) dazu linken, die ausserdem noch von Commodore
> mit zweifelhaften `Perlen' ala voellig inkompatibler stdio-Funktionalitaet
> bereicht wuerde, und im andern Fall halt nicht!

    Dieses Problem (sofern es eins ist) kann einfach umschifft
werden, indem man sich den Varargs-Stub _selbst_ schreibt. Niemand muss
mit amiga.lib linken, wenn er nicht will.

> >ARRAY's anlegen will, der soll's doch bitte _statisch_ tun! Das tut
>
> Noe.. laengst nicht alle Tag-Arrays sind statisch, und wenn Du beginnst,
> statische Arrays dann nachtraeglich doch noch zur Laufzeit zu aendern (und
> das ueblicherweise natuerlich nicht durch Semaphoren schuetzt), dann ist
> die Reentrancy zum Teufel.

    Das sollte man natuerlich nicht! Deswegen ja auch der
folgende Absatz! Bitte nicht mehr sinnentstellend quoten! Ich sagte
keineswegs, dass statische Tag-Arrays _immer_ Sinn machen. Es kommt
auf das Wort "solange" (s.u.) an. Fuer solche Faelle hatte ich ausserdem
vorgeschlagen, Varargs und statische Tags zu mischen, falls moeglich.

> >einer moeglicherweise gewuenschten Reentrancy solange keinen Abbruch,
> >wie sie 'const' definiert und benutzt werden, was zusaetzlich noch
> >den netten Nebeneffekt hat, dem Compiler eine Optimierungschance
> >mehr einzuraeumen. Und Bezeichnerkonflikten geht man aus dem Weg,
>
> Schon klar, dass const Objekte huebsche Hinweise fuer den Compiler beinhalten,
> nur gibtst Du diesem dadurch, dass Du die Objekte in statischen Speicher
> forcierst (!) keine Chance, sie gaenzlich inline zu expandieren, was ich
> schade finde.

    Was ist "schade"? Beschreibe doch mal bitte, was diese
"Inline expansion", was immer damit gemeint sei, in diesem Zusammenhang
an Vorteilen bringt? Ich kann nicht nachvollziehen, inwieweit man die
Zusammenstellung von Daten optimieren kann, die bereits in einer Form
vorliegen, dass man sie 1:1 aus dem Lademodul uebernehmen kann. Unter
der Voraussetzung, dass die verarbeitende Funktion einen _Pointer_ auf
diese Daten erwartet, versteht sich.

> >    Ich kann also nicht nachvollziehen, welche tiefere
> >Bedeutung dem Ansinnen zukommt, zur Laufzeit 'automatic' Tagarrays
> >anlegen zu wollen? m.E. bringt das keine zusaetzlichen Vorteile.
>
> Siehe oben. Ausserdem, je mehr Daten Du dem Compiler zur Verfuegung stellst,
> aus denen er versuchen kann, das Optimum rauszuholen, desto besseren Code
> wird er erzeugen.

    Redundanzen koennen nie zu mehr als 100% entfernt werden.
Also der gleiche Effekt, als wenn man sie erst gar nicht erzeugt
(was ich versuche, zu propagieren). Darueber den _Compiler_ brueten
zu lassen, erachte ich zumindest als ineffizient (da kommt halt der
Oekonom durch, Informatiker moegen sich an solchen Effekten schon
aus rein wissenschaftlichem Interesse ergoetzen). Es ist zwar schoen,
wenn ein Compiler sowas kann, aber koennte er in dieser Zeit nichts
Sinnvolleres anstellen? Die Rechnung "Mehr Code => Mehr Optimierung"
scheint mir jedenfalls _etwas_ widerspruechlich! :-)

> In diesem Fall (jetzt mal von dynamischen Daten aus-
> gehend) hat er entweder die Wahl, zu einem bestimmten Zeitpunkt alle
> Werte zu instantiieren und per Stack an die Varargs Funktion zu uebergeben
> (womit a0/a1/d0/d1 ja wegfallen als Datentraeger), oder sie womoeglich
> ohne Umwege direkt nach erfolgter Berechnung in die spaeter der OS-Funktion
> zu uebergebende Tag-Struktur zu schreiben. Aus diesem Blickwinkel kriegst
> Du mit der Varargs-Version garantiert die schlechteste Loesung, auch wenn
> nicht garantiert ist, dass die andere Variante besser ist.

    - a0/a1/d0/d1 fallen frueher oder spaeter _immer_ weg, denn
    wir wollen ja eine Systemfunktion -direkt oder indirekt- aufrufen.

    - Die Werte werden auf dem Stack uebergeben, und da _bleiben_
    sie dann auch, weil der Stack damit zum TagArray _wird_.

    - 'automatic'-Variablen werden gemeinhin _auch_ nirgendwo
    anders als auf dem Stack instantiiert. Jede Abweichung
    hiervon erzeugt _nochmals_ zusaetzlichen Code zur Speicher-
    beschaffung, Verwaltung und abschliessender Freigabe.

    - Die Schlussfolgerung ist in diesem Zusammenhang falsch.

> >    Strings initialisiert man in C gemeinhin _immer_ statisch.
> >Zur Laufzeit geht das nur mit strcpy() e.a..
>
> Ooch.. bist Du aber K&R treu.. nur weil das immer so war, muss das doch
> nicht immer so bleiben?!

    Was gewinnt man durch die automatic-Deklaration von Strings?
Ein _builtin_strcpy() vom (in diesem Falle dann _doch_ wieder statisch
initialisierten) DATA-Segment auf den Stack? Doppelter Speicherbedarf,
zusaetzlicher Code! (Womit nicht gesagt sein soll, dass es fuer diesen
Mehraufwand niemals eine Rechtfertigung geben mag). Ich bin nur sehr
vorsichtig mit "Segnungen" dieser Art. Wer zeitkritische Applikationen
schreibt, mag hunderte von builtin-Funktionen und damit verbundene
Codegenerierung erdulden [nur am Rande: strcpy() ist m.E. _selten_ der
ideale Ansatzpunkt fuer Optimierungen], ansonsten erzeugen Funktionsaufrufe
aber regelmaessig _kuerzeren_ Code. Keine Frage "K&R vs. ANSI" sondern ganz
einfach "Effizienz vs. Komfort"!

> Es ist doch durchaus huebsch, mktemp(3) so
> zu implementieren:
>   char template[] = "ram:t/tmpl.XXXXXX";

    "Huebsch" ist eine subjektive Empfindung. Tatsache ist, dass
im fertigen Objektmodul sowohl der initiale Stringinhalt im DATA-
Segment steht, zum Funktionseintritt als erstes von dort auf den
Stack _umkopiert_ wird, um dann gleich wieder in subsequenten
Konstrukten _ueberschrieben_ zu werden. Da bleibt die Effizienz doch
irgendwo auf der Strecke, findest Du nicht? Selbst unter der Annahme,
dass der erste Schritt "wegoptimiert" wird (der Compiler finde irgendwie
(?) heraus, dass der initiale Inhalt von template[] nicht benoetigt werde),
gewinnt man mit dieser Moeglichkeit unterm Strich _nichts_.

> [...] Die ANSI-Variante sieht nicht
> nur schoener aus, sondern ist auch einfacher zu verwenden, IMHO ;-)

    Die Frage lautet halt immer: "Wieviel Bytes ist Dir
Deine Faulheit wert" :-) :-).

> Markus M. Wild    -  [e-mail]  |  [e-mail]

--
Best regards,
Franz-Josef Reichert   GERMANY - VOICE: [phone]
Kuchlingerstrasse 13   UUCP: fjrei@kbsaar.{saar|adsp}.sub.org
6601 Kleinblittersdorf        [e-mail]

From de.comp.sys.amiga.misc Thu Jul  2 00:53:09 1992
Path: cs.tu-berlin.de!news.netmbx.de!Germany.EU.net!unido!sbsvax!coli-gate.coli.uni-sb.de!uhf!kbsaar!kbsaar!fjrei
From: [e-mail] (Franz-Josef Reichert)
Newsgroups: de.comp.sys.amiga.misc
Subject: Re: TagItems und C-Compiler
Message-ID: <WMnhr*[e-mail]>
Date: 1 Jul 92 14:03:38 GMT
References: <5pcer*[e-mail]> <[e-mail]>
 <2Umfr*[e-mail]> <[e-mail]> <KlTgr*[e-mail]>
 <[e-mail]>
Reply-To: [e-mail] (Franz-Josef Reichert)
Organization: Private Amiga Site
Lines: 57
X-Newsreader: Arn V1.00 beta rel2

In article <[e-mail]>, Andreas M. Kirchwitz writes:

> In <KlTgr*[e-mail]> [e-mail] (Franz-Josef Reichert) writes:
>
> >    Strings initialisiert man in C gemeinhin _immer_ statisch.
>
> Ach ja?  Ist mir neu...

    Initialisierung = VORbelegung von Speicherzellen mit bestimmten
        Inhalten.

    Statisch = i.S.v. Wertbestimmung _vor_ der Laufzeit.

    Mit "statischer Initialisierung" bezeichne ich demnach, dass bei
allen Stringinitialisierungen der resultierende String-Inhalt bereits _vor_
der Laufzeit festzustehen hat, das "immer" impliziert, dass es in 'C' nicht
anders moeglich ist. Was einfach daran liegt, dass C i.d.R. compiliert, nicht
interpretiert wird. Was ist daran unklar? Wie kann ich etwas "VORbelegen",
wenn ich zum Zeitpunkt der VORbelegung noch gar nicht weiss, welche Werte
das vorzubelegende Objekt erhalten soll? Das waere doch ein ganz klarer
Widerspruch!

> >Zur Laufzeit geht das nur mit strcpy() e.a..
>
> Mitnichten.

    Was Du meinst, ist "dynamisches Ausfuellen von Stringinhalten".
In der Praxis laeuft dies aber immer auf ein (bestenfalls) inline-strcpy()
hinaus, dessen Quelldaten in den meisten Faellen auch noch aus statischen
Daten bedient werden. Sobald ich im C-Source irgendwas zwischen doppelte
Anfuehrungszeichen setze, kann ich davon ausgehen, dass der Compiler daraus
auch statische Daten erzeugt. Womit ich statische Daten gewinne, nicht
aber vermeide. Der signifikante Unterschied zwischen (1)

        test1() {
            unsigned char string[] = "Laberfasel";
        }

    und (2)

        test2() {
            static unsigned char string[] = "Laberfasel";
        }

    ist nunmal, dass (2) _weniger_ Code erzeugen _muss_!

>         Mit Unverstaendnis...  Andreas

    Ueber mangelhafte Effizienz des (dynamischen) Umkopierens (aus
ihrer Definition heraus bereits) statischer Dateninhalte braucht aber nicht
diskutiert zu werden? Oder etwa doch? :-)

--
Best regards,
Franz-Josef Reichert   GERMANY - VOICE: [phone]
Kuchlingerstrasse 13   UUCP: fjrei@kbsaar.{saar|adsp}.sub.org
6601 Kleinblittersdorf        [e-mail]

From de.comp.sys.amiga.misc Fri Jul 10 21:20:13 1992
Path: cs.tu-berlin.de!news.netmbx.de!Germany.EU.net!unido!horga!ruhr.de!erni.bs.open.de!germal!germal.bs.open.de!gm
From: [e-mail] (Gerald Malitz)
Newsgroups: de.comp.sys.amiga.misc
Subject: Re: TagItems und C-Compiler
Message-ID: <vQ+jr*[e-mail]>
Date: 9 Jul 92 08:07:59 GMT
References: <JcBgr*[e-mail]> <[e-mail]>
 <Ebnir*[e-mail]> <[e-mail]>
Lines: 77
X-Newsreader: Arn V1.00 beta rel2

In article <[e-mail]>, Markus Wild writes:

> In article <Ebnir*[e-mail]> [e-mail] (Gerald Malitz) writes:
> >    Strings haben im Code-Hunk nichts zu suchen, denn sie sind
> >ja nun mal nicht executable.  Veraenderlich - im Sinne von nicht vor
> >Schreibzugriffen geschuetzt - sind sie beim Amiga ja in jedem Fall, Exec
> >bietet kein Protected-Memory.  Andererseits kann ein Programm mehrere
>
> Diese Unterscheidung ist ja nur wichtig, wenn Du residentfaehige Programme
> schreiben willst, deshalb hab ich das ja explit erwaehnt. In diesem Falle
> kannst Du Dir nicht mehrere Data-Hunks leisten, da Du ja mit A4 alle DATA
> Objekte erreichen musst. Chip-Data Hunks sind unter diesen Umstaenden auch
> speziell, und muessen wie CODE Hunks behandelt werden, denn wenn sie auch
> veraenderlich sind, hast Du im Nu ein nicht-pures Programm.

    Natuerlich koennen residentfaehige Programme mehrere Data-Hunks
haben, und sie haben sie auch.  Lediglich die globalen veraenderlichen
Daten muessen relativ adressiert werden.  Die Konstanten - um genau die
geht es ja - koennen ebenso wie der Code gemeinsam benutzt werden.  Sie
werden in jedem Fall absolut adressiert, ob sie nun in einem Code oder
einem Datensegment liegen.  Wenn Du das Beispielprogramm von Andreas mal
compilierst, hast Du (zumindest mit SAS) ein Executable mit drei Hunks:
dem Code-Hunk und zwei Daten-Hunks, einer enthaelt die globalen Variablen
des Programms (in dem Fall hauptsaechlich aus der Linklibrary), der andere
die Konstanten (in dem Fall den String "Hello World\n").  Letzterer muss
eben nicht in den Code-Hunk.

    Deshalb bekommt Andreas ja auch Probleme, wenn er dem Linker
die Option SMALLDATA mitgibt.  Dann werden diese beiden Data-Hunks
zusammengefasst.  Wenn er Pech hat, landet am Ende alles - auch die
Variablen - im Hunk fuer globale Konstanten.  Klar, dass das schief
geht.

> >die erste Wahl.  (Btw. wer seine Strings nun doch unbedingt unter den
> >Code gemixt haben will, soll sich aus dem Handbuch eine geeignete
> >Compileroption suchen.  Die gibt es naemlich auch.  Aetsch.  Helfen
> >wuerde es in diesem Fall aber auch nicht.)
>
> Aeh, wer sagt denn, dass Exec *nie* Protected Memory bieten wird?

    Und wovon traeumst Du Nachts ;^)

> Genauso wenig wie es Protected Memory gibt im Moment, gibt's Protected
> Hunks, also steht's 1:1, aetsch zurueck;-)))

    Abseits, ganz klar! =:^>  Dir fehlt nach wie vor der Grund,
Daten in den Code zu mischen - da sie ja so oder so nicht geschuetzt
sind und in jedem Falle absolut% adressiert werden muessen.

    % mindestens aber pc-relativ, das ist aber auch nicht ohne,
da bei SAS die Module auf 64K beschraenkt sind.

> Helfen tut es immer dann,
> wenn residentfaehige Programme mit moeglichst viel Data erzeugt werden
> sollen.

    Helfen kann ich nur dann, wenn Konstanten da sind, die aus
dem relativ zu a4 adressierten Bereich herausgenommen werden koennen.
Die muss ich aber nicht in ein Code-Segment packen, sondern kann sie -
wie oben beschrieben - auch in einem eigenen Daten-Segment unterbringen.

    Nebenbei: das Erzeugen residenter Progamme mit cres.o ist IMHO
sowieso nur ein Hack, fuer den man einen Preis zahlt.  Die globalen
Variablen sind auf 64K beschraenkt (schoenen Gruss an die DOSe), das
ganze fuehrt leicht zu Verwirrungen (Blink-Warnings) oder Abstuerzen
(Option SMALLDATA) und __saveds bzw. geta4() tun auch nicht mehr wie
gewuenscht.

> -Markus

    Tschuess, Gerald.

--
  // Gerald Malitz,  Bolchentwete 4,  3300 Braunschweig,  Voice: [phone]
\X/ [e-mail]    "Allein der K|ndigungsschutz f|r Schwangere hat den
ungeborenen Kindern tausendfach mehr geholfen als alle Kardindle, Staatsanwdlte
und Richter zusammengenomen"                                     Heiner Gei_ler

From de.comp.sys.amiga.misc Fri Jul 24 19:21:24 1992
Path: cs.tu-berlin.de!news.netmbx.de!Germany.EU.net!unido!horga!ruhr.de!erni.bs.open.de!germal!germal.bs.open.de!gm
From: [e-mail] (Gerald Malitz)
Newsgroups: de.comp.sys.amiga.misc
Subject: Re: Initialisierung, C-Experte gesucht
Message-ID: <5-por*[e-mail]>
Date: 22 Jul 92 20:18:45 GMT
References: <[e-mail]> <[e-mail]>
 <sgilr*[e-mail]> <[e-mail]> <zYMmr*[e-mail]>
 <[e-mail]>
Lines: 27
X-Newsreader: Arn V1.00 beta rel2

In article <[e-mail]>, Ralph Babel writes:

> > Link das Programm zusaetzlich mit SMALLDATA.  Du wirst ein
> > defektes Executable erhalten :-(
>
> Das kann ich nicht reproduzieren:

    Das tritt auch nur in einem Sonderfall auf, naemlich
wenn printf ohne fmt aufgerufen wird (wir hatten als ein
Beispiel ein char[] als autoinit-Variable).  Dann hat das
Objectfile keinen __MERGED-Hunk, und das findet Blink wohl
nicht so toll :)  Was passiert, wenn es mehrere Objectfiles
gibt, von denen ein paar diesen Hunk haben, andere aber nicht,
habe ich noch nicht probiert (interessiert mich auch nicht so
brennend).

    Grundsaetzlich hat Andreas mit den Probelemen
schon recht, sie sind da.  Aber das Drama, das er daraus
macht, ist reif fuer den MB-award.

> Ralph

    Tschuess, Gerald.

--
  // Gerald Malitz,  Bolchentwete 4,  3300 Braunschweig,  Voice: [phone]
\X/ [e-mail]                   ISO?  Nicht immer, aber immer vfter.