home *** CD-ROM | disk | FTP | other *** search
/ back2roots/padua / padua.7z / padua / text / TagItems / text0000.txt < prev    next >
Encoding:
Text File  |  2014-05-19  |  3.5 KB  |  105 lines
  1. amk@zikzak.in-berlin.de (Andreas M. Kirchwitz) writes:
  2. :[line eater was here]
  3. :
  4. :     void meine_kleine_prozedur(void) {
  5. :     {
  6. :       ULONG tags[] = {RT_WaitPointer,TRUE,TAG_END};
  7. :       if (rtGetStringA(str,len,title,NULL,(struct TagItem *)tags))
  8. : 
  9. :       [...]
  10. :     }
  11. : 
  12. : 
  13. : Der Compiler (SAS/C) findet das toll.  Der Linker meint dazu jedoch:
  14.  
  15. Das entsetzt mich. Nicht Dein Quellcode, sondern dass der Compiler
  16. nicht meckert... Damit Du weinger Probleme mit meinem Erklaeungs-
  17. versuch hast, erst mal ein paar Begriffsbestimmungen (ja, wie in
  18. der Vorlesung :-)
  19.  
  20. * Speicherklasse: C laesst als "Modifizierer" fuer Datentypen Angaben
  21.   ueber die Verwaltung von Variablen zu. Als da waeren:
  22.  
  23.   - extern : Speicherplatz fuer die Variable/Funktion wird nicht hier,
  24.     sondern in einem anderen Modul zur Verfuegung gestellt.
  25.  
  26.   - auto : Zulaessig nur fuer Variablendeklarationen innerhalb von
  27.     Funktionen (ist da auch Voreinstellung). Speicherplatz wird zur
  28.     Laufzeit des Programms auf dem Prozessor-Stack reserviert.
  29.     Dies geschieht "automatisch" beim Betreten des fraglichen Blocks.
  30.  
  31.     Die Lebensdauer von Variablen dieser Speicherklasse reicht nur bis
  32.     zum Verlassen des Blocks, danach sind sie "weg".
  33.  
  34.   - static : Hier gibt's zwei Bedeutungen, je nachdem wo die Deklaration
  35.     steht (seufz)
  36.  
  37.     = ausserhalb einer Funktion : Das deklarierte Objekt ist nur inner-
  38.       halb des aktuellen Moduls bekannt. Das erlaubt die mehrfache Ver-
  39.       wendung von Namen in verschiedenen Modulen.
  40.  
  41.     = innerhalb einer Funktion : Das deklarierte Objekt wird nicht zur
  42.       Laufzeit, sondern bereits zur Compilationszeit "statisch" erzeugt.  
  43.       Das erlaubt dem Compiler, diese Variablen vorzubesetzen, und ver- 
  44.       laengert die Lebensdauer der Variable ueber das Verlassen der
  45.       Funktion hinaus. Das Objekt ist aber nur innerhalb des Blocks
  46.       bekannt, indem es deklariert wurde.
  47.  
  48.   - register : Das Compiler versucht das Objekt wird in Registern des
  49.     Prozessors unterzubringen, sofern moeglich. Beachte, dass Register
  50.     keine Addresse haben. Programmstuecke wie:
  51.  
  52.     :
  53.     register int x;
  54.     :
  55.     scanf("%d", &x);
  56.     :
  57.  
  58.     zeigen ein voellig undefiniertes Verhalten.
  59.  
  60. Zurueck zu Deinem Problem - Wenn ich's recht in Erinnerung habe, geht
  61. es so:
  62.  
  63. Initialisierung in der Deklaration von Variablen am Beginn eines
  64. Blocks ist moeglich fuer:
  65.  
  66.    - "einfache" Variablen (also int, char, float, double...)
  67.  
  68.    - Variablen "komplexer" Datentypen (arrays, structs, ...)  NUR in
  69.      der Speicherklasse "static".
  70.  
  71. "static" muss explizit angegeben werden, default ist "auto". Schreibe also
  72.  
  73.         :
  74.         static ULONG tags[]....
  75.         :
  76.  
  77. und Dein Code sollte korrekt uebersetzt und gelinkt werden. Die
  78. Initialisierung erfolgt zur Compilationszeit und wird bei erneutem
  79. Aufruf von "meine_kleine_prozedur()" nicht nochmal durchgefuehrt!
  80.  
  81. Statt dessen hast du in tags[] immer noch die Werte stehen, die beim
  82. letzten Verlassen der Prozedur drin waren.
  83.  
  84. :     Warning! Absolute reference to UNKNOWN
  85. :      module: rtsup.c        file: rtsup.o
  86. :
  87.  
  88. Klar. Der Linker suchte ein Objekt zum initialisieren, dessen Speicher-
  89. platz noch gar nicht bekannt sein kann. Aber warum erst der Linker das
  90. bemerkt? Warten wir auf SAS/C 6.0 :-(
  91.  
  92. So, das war lang. Ich hoffe, ich konnte etwas Licht ins Dunkel
  93. bringen...
  94.  
  95. Kalahari,
  96.    Michael Boehnisch,
  97.    billy@uni-paderborn.de
  98.  
  99. -- 
  100.  
  101. _________________________________________________________
  102. *** Michael Boehnisch                                 ***
  103. *** billy@uni-paderborn.de    I disclaim everything.  ***
  104.  
  105.