C: const array in header, warum wird linker probleme machen?

[dotm (Gast)]

Hallo!

Das ist ein wahrscheinlich einfaches Thema aber das ganze ist so 
unübersichtlich dass ich dennoch nachfragen muss.
Der Ursprung meines Problemes ist der, dass ich meinen 
Mikrocontrollercode auf ein eventuelles Pinswapping vorbereiten wollte.
In den Beispielen von STM wird das eigentlich ganz elegant erledigt. 
Aufgrunddessen hab ich jetzt beispielsweise sowas konstruiert:

config.h wäre dann die datei wo ich meine pins und ports eintrage:

#define DIGITAL_OUTn    7

typedef enum
{
EN_FILTER = 0,
EN_MODEM = 1,
EN_SENSOR = 2,
} DIGITAL_OUT_TypeDef;

#define EN_FILTER_PIN          GPIO_Pin_1
#define EN_FILTER_GPIO_PORT    GPIOA
#define EN_FILTER_GPIO_CLK     RCC_AHBPeriph_GPIOA
#define EN_FILTER_GPIO_SPEED   GPIO_Speed_2MHz

#define EN_MODEM_PIN           GPIO_Pin_9
#define EN_MODEM_GPIO_PORT     GPIOB
#define EN_MODEM_GPIO_CLK      RCC_AHBPeriph_GPIOB
#define EN_MODEM_GPIO_SPEED    GPIO_Speed_2MHz
 
#define EN_SENSOR_PIN          GPIO_Pin_8
#define EN_SENSOR_GPIO_PORT    GPIOB
#define EN_SENSOR_GPIO_CLK     RCC_AHBPeriph_GPIOB
#define EN_SENSOR_GPIO_SPEED   GPIO_Speed_2MHz

config.c beinhaltet jetzt noch das:

#include "config.h"

const uint16_t DIGITAL_OUT_PIN[DIGITAL_OUTn] =
  {
EN_FILTER_PIN, EN_MODEM_PIN, EN_SENSOR_PIN
  };

GPIO_TypeDef* DIGITAL_OUT_PORT[DIGITAL_OUTn] =
  {
EN_FILTER_GPIO_PORT, EN_MODEM_GPIO_PORT, EN_SENSOR_GPIO_PORT
  };

const uint32_t DIGITAL_OUT_CLK[DIGITAL_OUTn] =
  {
EN_FILTER_GPIO_CLK, EN_MODEM_GPIO_CLK, EN_SENSOR_GPIO_CLK, 
  };

const uint8_t DIGITAL_OUT_SPEED[DIGITAL_OUTn] =
  {
EN_FILTER_GPIO_SPEED, EN_MODEM_GPIO_SPEED, EN_SENSOR_GPIO_SPEED,
  };

jetzt kann ich innert config.c noch solche schönen funktionen schreiben:

void DigitalOutInit(DIGITAL_OUT_TypeDef DIGITAL_OUT)
  {
  GPIO_InitTypeDef GPIO_InitStructure;

  /* Enable the GPIO Clock */
  RCC_AHBPeriphClockCmd(DIGITAL_OUT_CLK[DIGITAL_OUT], ENABLE);

  /* Configure the GPIO pin */
  GPIO_InitStructure.GPIO_Pin = DIGITAL_OUT_PIN[DIGITAL_OUT];
  GPIO_InitStructure.GPIO_Mode = GPIO_Mode_OUT;
  GPIO_InitStructure.GPIO_OType = GPIO_OType_PP;
  GPIO_InitStructure.GPIO_PuPd = GPIO_PuPd_NOPULL;
  GPIO_InitStructure.GPIO_Speed = DIGITAL_OUT_SPEED[DIGITAL_OUT];
  GPIO_Init(DIGITAL_OUT_PORT[DIGITAL_OUT], &GPIO_InitStructure);
  }

Aufgerufen wird das also dann mit:

DigitalOutInit(EN_FILTER);

so weit so wunderbar.
Jetzt dachte ich mir wär doch schön wenn ich in einem anderm Modul zb 
GPIO.c auch noch solche Funktionen verwenden könnte

// folgende Zeile geht noch:
void SetPin(DIGITAL_OUT_TypeDef DIGITAL_OUT)
{
// folgende Zeile geht nicht, wenn ich nur #include "config.h" mache,
// weil die const arrays aus config.c unbekannt sind.
GPIO_SetBits(DIGITAL_OUT_PORT[DIGITAL_OUT],DIGITAL_OUT_PIN[DIGITAL_OUT]);
}

mein erster Gedanke war also den Inhalt von config.c einfach in config.h 
reinzumachen weil ich sowieso so ein Konstrukt habe:

#ifndef INIT_CONFIG_H_
#define INIT_CONFIG_H_

// hier der headercode

#endif

offensichtlich nicht, weil laut folgendem Beitrag:
Beitrag "Re: const array in header auslagern"
der Linker sich dennoch beschweren wird.

das muss also z.B. via

extern uint16_t DIGITAL_OUT_PIN;

in der config.h gelöst werden. (ja? nein?)

Kann mir jemand erklären wieso der linker trotz #ifndef muckt?
Gibt es eine Möglichkeit dass ich das nur mit einer headerfile machen 
kann?
Ich würde mir echt gerne die config.c (und auch das notwendige 
mitverlinken) und die doppelschreiberei ersparen...

[Verne (Gast)]

Hier sind zwei Irrtümer maßgebend.
1. Der Linker "muckt" nicht, sondern reagiert sinnvoll auf dass, was Du 
in C geschrieben hast.
2. Der Linker hat mit #ifdef uws. nichts zu tun. Das ist Sache des 
Präprozessors.

Das #ifndef verhindert/befördert ja nur ob das config.h included wird 
oder nicht. Der Hauptzweck dieses Konstrukts, ist es zu verhindern, das 
include files mehrfach included werden.
Mit der Deklaration/Definition Deiner Variablen aber hat das nichts zu 
tun. Da musst Du in der Tat eine Methode finden, wie Du zwischen

extern uint16_t DIGITAL_OUT_PIN;

und

const uint16_t DIGITAL_OUT_PIN[...

auswählst.

Das ist garnicht so schwer und benutzt im Grunde den selben Gedankengang 
wie das obige #ifdef. Überleg mal selbst.

[dotm (Gast)]

also, was ist eigentlich das Problem wenn ich das Array direkt in die 
headerfile schreibe.
Der Compiler wird die header einmal aufrufen und danach ist das Array 
global (oder eben nicht?) deklariert.
Ich denke was du mir sagen willst ist, dass das Array dann NUR für die 
aufrufende Funktion deklariert ist.. (?)
Könnte das eine Lösung sein?
config.h enthält also auch:

#ifndef INIT_CONFIG_H_
const uint16_t DIGITAL_OUT_PIN[DIGITAL_OUTn] =
  {
EN_FILTER_PIN, EN_MODEM_PIN, EN_SENSOR_PIN
  };
#endif

#ifdef INIT_CONFIG_H_
extern uint16_t DIGITAL_OUT_PIN;
#endif

Das würde heissen dass das Array zwar im ersten Durchlauf global 
deklariert wird aber immer noch mit jedem weiteren Modul (.c Datei) 
durch extern verbunden werden muss.

Das ist mir ein bisschen unklar. Wenn meine main.h die datei config.h 
inkludiert, dann müsste doch das array global ohne weiteres "extern" zur 
Verfügung stehen?
Wenn ich ein einzelnes Modul (z.B. GPIO.c) kompiliere dann ist 
INIT_CONFIG_H_ ja noch nicht definiert und das Modul sollte doch ohne 
Probleme kompilierbar sein.

[Rufus Τ. F. (rufus)]

Verne schrieb:
> 1. Der Linker "muckt" nicht, sondern reagiert sinnvoll auf dass, was Du
> in C geschrieben hast.

So kann man das natürlich auch "interpretieren".

Das Problem, das hier auftritt, ist, daß für jede Objektdatei, die mit 
eingebundener Headerdatei erzeugt wird, jeweils eine Kopie des 
const-Array angelegt wird. Wenn diese nicht als statisch definiert 
sind, d.h. nur innerhalb der Objektdatei sichbar, dann beschwert sich 
der Linker --zu Recht-- über mehrfach definierte Symbole.

Der gcc-Linker bietet die Möglichkeit, diese Definitionen zu überlagern 
und zu einem zusammenzufassen (so daß die Warnung nicht mehr auftritt), 
aber das kann auch Probleme erzeugen, wenn nämlich die Symbole 
eigentlich unterschiedlich sein sollten. Dann verdeckt diese Möglichkeit 
den Fehler, den man dann recht aufwendig suchen muss.

Daher sollte --meiner Ansicht nach-- auf diese Möglichkeit verzichtet 
werden, zumal das eine gcc-Spezialität ist, und andere C-Compiler bzw. 
deren Linker sowas nicht unterstützen.



In Headerdateien gehören nur Deklarationen, also Erklärungen, daß es 
irgendwo ein Objekt mit diesen und jenen Eigenschaften gibt, aber 
nicht die Definition des Objektes, die festlegt, daß es hier dieses 
Objekt gibt.

const uint16_t DIGITAL_OUT_PIN[DIGITAL_OUTn] =
  {
EN_FILTER_PIN, EN_MODEM_PIN, EN_SENSOR_PIN
  };

Das ist eine Definition.

Die korrespondierende Deklaration sieht so aus:

extern const uint16_t DIGITAL_OUT_PIN[DIGITAL_OUTn];

"Include-Guards", also das Verpacken in #ifdef & Co. helfen nur, wenn 
sie so genutzt werden, daß nur für eine C-Datei die Definition 
vorhanden ist.

Dann aber kann man es auch richtig machen und Definition und Deklaration 
trennen.


Nochwas: Variablennamen, wie Dein DIGITAL_OUT_PIN, gehören nicht in 
Großbuchstaben geschrieben. Das ist Macros, also mit #define definierten 
Dingen vorbehalten - und je nach Philosophie des Entwicklers einzelnen 
enum-Werten sowie typedefs.

----

Anmerkung:

In einem durch einen langen Arbeitstag vielleicht begründbaren Anfall 
geistiger Umnachtung habe ich, als ich das gestern schrieb, recht 
konsequent Definition und Deklaration durcheinandergebracht.
Das habe ich jetzt korrigiert -- mit Dank an den aufmerksamen Leser 
Stefan Ernst.

[Stefan E. (sternst)]

Rufus Τ. Firefly schrieb:
> In Headerdateien gehören nur Definitionen, also Erklärungen, daß es
> irgendwo ein Objekt mit diesen und jenen Eigenschaften gibt, aber
> nicht die Deklaration des Objektes, die festlegt, daß es hier dieses
> Objekt gibt.

Bedeutung von "Definition" und "Deklaration" ist genau anders herum.

[Stefan E. (sternst)]

@ dotm:

Ein #define wirkt sich nicht Modul übergreifend aus. Zweck der 
Include-Guards ist ausschließlich, das mögliche mehrfache Einbinden 
eines Headers in ein und das selbe Modul zu unterbinden.

[dotm (Gast)]

Rufus Τ. Firefly schrieb:
> In Headerdateien gehören nur Definitionen, also Erklärungen, daß es
> irgendwo ein Objekt mit diesen und jenen Eigenschaften gibt, aber
> nicht die Deklaration des Objektes, die festlegt, daß es hier dieses
> Objekt gibt.

Das verstehe ich, in diesem Spezialfall jedoch wäre es einfacher, weil 
dann der Hardwaredesigner (also eh auch ich...) nur eine Datei und zwar 
config.h ändern muss.

Rufus Τ. Firefly schrieb:
> Nochwas: Variablennamen, wie Dein DIGITAL_OUT_PIN, gehören nicht in
> Großbuchstaben geschrieben. Das ist Macros, also mit #define definierten
> Dingen vorbehalten - und je nach Philosophie des Entwicklers einzelnen
> enum-Werten sowie typedefs.

jetzt hast du mich erwischt.

Rufus Τ. Firefly schrieb:
> Wenn diese nicht als statisch deklariert
> sind, d.h. nur innerhalb der Objektdatei sichbar, dann beschwert sich
> der Linker --zu Recht-- über mehrfach definierte Symbole.

Was, wenn ich die Deklarationen der const Arrays ausserhalb des 
Include-Guards in die header Datei schreibe, aber als static.
Dann müssten sie pro .o einmal zur Verfügung stehen. Wäre das eine 
Lösung?

Auch Interessant ist das Macro aus dem Beitrag:
Beitrag "Re: Globale Variablen, mehrere Dateien"

#ifndef EXTERN
#define EXTERN extern
#endif

EXTERN int GlobaleVar1;
EXTERN int GlobaleVar2;

Aber ich denke sowas geht nur wenn ich die Variable nicht initialisiere.
Oder frisst der Compiler sowas:

extern int meine_lieblingszahlen[2] =
{
666,1337
};

[dotm (Gast)]

dotm schrieb:
> Was, wenn ich die Deklarationen der const Arrays ausserhalb des
> Include-Guards in die header Datei schreibe, aber als static.
> Dann müssten sie pro .o einmal zur Verfügung stehen. Wäre das eine
> Lösung?

AAAAHH!!!:

Stefan Ernst schrieb:
> Ein #define wirkt sich nicht Modul übergreifend aus. Zweck der
> Include-Guards ist ausschließlich, das mögliche mehrfache Einbinden
> eines Headers in ein und das selbe Modul zu unterbinden.

[Mark B. (markbrandis)]

Stefan Ernst schrieb:
> Rufus Τ. Firefly schrieb:
>> In Headerdateien gehören nur Definitionen, also Erklärungen, daß es
>> irgendwo ein Objekt mit diesen und jenen Eigenschaften gibt, aber
>> nicht die Deklaration des Objektes, die festlegt, daß es hier dieses
>> Objekt gibt.
>
> Bedeutung von "Definition" und "Deklaration" ist genau anders herum.

Richtig. Deklaration = ich erkläre dem Compiler, dass eine Variable oder 
Funktion mit diesem Namen und Typ irgendwo existiert.  Definition = 
Ausprogrammieren einer Funktion, bzw. Anlegen (und ggf. Initialisieren) 
einer Variablen im Speicher.

[Karl H. (kbuchegg)]

dotm schrieb:

> Aber ich denke sowas geht nur wenn ich die Variable nicht initialisiere.
> Oder frisst der Compiler sowas:
>
>

> extern int meine_lieblingszahlen[2] =
> {
> 666,1337
> };
>

Um das noch zu beantworten:
Schreiben kannst du es. Aber das Problem an der Sache ist, dass eine 
Initialisierung aus einer Deklaration eine Definition macht. D.h. durch 
die Initialisierung fällt das 'extern' stillschweigend unter den Tisch.

[dotm (Gast)]

Also:
Verne schreibt oben dass es möglich ist zwischen const und extern zu 
schalten.
Ich denke aber dass das nicht möglich ist. Wie soll denn der Compiler 
wissen dass schon ein Objekt mit dem array erstellt worden ist?

[Rufus Τ. F. (rufus)]

Stefan Ernst schrieb:
> Bedeutung von "Definition" und "Deklaration" ist genau anders herum.

Oh, Mist. Hast recht. War ein langer Tag gestern -- manchmal macht das 
Hirn schlapp.

Habe das in o.g. Geschreibsel von mir jetzt korrigiert, siehe auch die 
dortige Anmerkung.

[Stefan W. (dl6dx)]

dotm schrieb:
> Gibt es eine Möglichkeit dass ich das nur mit einer headerfile machen
> kann?
> Ich würde mir echt gerne die config.c (und auch das notwendige
> mitverlinken) und die doppelschreiberei ersparen...

Ein möglicher Weg wäre, ein spezielles Präprozessorsymbol für die 
"Umschaltung" zwischen Deklaration und Definition zu verwenden. Eine 
einzelne Kombi-Deklaration/Definition sähe dann in etwa so aus:

#ifndef CREATEVAR
extern
#endif
const uint16_t DIGITAL_OUT_PIN[DIGITAL_OUTn]
#ifdef CREATEVAR
 =
  {
  EN_FILTER_PIN, EN_MODEM_PIN, EN_SENSOR_PIN
  }
#endif
;

Ist das Makro CREATEVAR definiert, wird die Variable definiert 
(erzeugt), andernfalls als extern deklariert (bekannt gemacht).

In der Moduldatei, in der die Definitionen erzeugt werden sollen, muss 
entsprechend vor dem Include ein #define CREATEVAR stehen.

#define CREATEVAR
#include "config.h"

In allen anderen Modulen darf es nicht definiert sein.

Grüße

Stefan

[dotm (Gast)]

Hallo Stefan.
Danke, ich habe die Lösung sogar schon gelesen. Das Problem daran ist 
dass ich stets das ganze Projekt neu builden muss. Wenn ich nur ein 
Modul kompiliere, dann muss ich das wieder manuell setzen. Wie siehts 
denn mit den build variables aus (in Eclipse kann ich die ja in den 
Projekteinstellungen setzen). Kann ich die aus dem code heraus zur 
Compilerlaufzeit ändern?

[Stefan W. (dl6dx)]

dotm schrieb:
> Das Problem daran ist
> dass ich stets das ganze Projekt neu builden muss.
> Wenn ich nur ein
> Modul kompiliere, dann muss ich das wieder manuell setzen.

Ich bin mir nicht sicher, ob da nicht noch ein Missverständnis vorliegt.

Das Makro CREATEVAR wird innerhalb der Headerdatei nicht definiert. Da 
wird nur auf eine vorhergehende Definition abgefragt. Um ein Modul, das 
den Header verwendet, neu zu übersetzen wird da also nichts geändert.

Die Definition von CREATEVARS erfolgt in genau einer C-Datei, nämlich 
der, in der die Deklaration der Variablen erfolgen soll (ich nenn sie 
jetzt mal "config.c") und zwar direkt vor der #include-Anweisung für 
config.h.

In allen anderen C-Dateien, die die Deklarationen ("extern ...") 
verwenden sollen, wird es nicht definiert. Da steht nur ein #include 
"config.h".

An der Build-Umgebung musst du für diese Technik gar nichts anpassen. Es 
reicht, wenn dort die normalen Quelltextabhängigkeiten bekannt sind.

Grüße

Stefan

[dotm (Gast)]

@stefan
ok danke!
danke auch an alle andern hilfreichen poster!

[Josef D. (jogedua)]

Stefan Wagner schrieb:
> Das Makro CREATEVAR wird innerhalb der Headerdatei nicht definiert. Da
> wird nur auf eine vorhergehende Definition abgefragt. Um ein Modul, das
> den Header verwendet, neu zu übersetzen wird da also nichts geändert.

Deshalb verwendet man besser in jeder Datei einen eindeutigen Namen, 
z.B. so:

// Test.c ----------------------------
#define SRC_Test_C_   // SRC + Dateiname
#include "Test.h"
// ...
 
// Test.h ----------------------------
#ifndef TEST_H_
#define TEST_H_

#ifdef SRC_Test_C_  
   #define SRC_Test_C_INIT
#else
   #define SRC_Test_C_ extern
#endif // SRC_Test_C_

// **** hier kommen die Deklarationen / Definitionen hin

#endif // TEST_H_

und an der Stelle **** z.B.

SRC_Test_C_  int var1;

SRC_Test_C_  int var2
#ifdef SRC_Test_C_INIT
  = 15
#endif
;

Dann kann man auch in der .h-Datei gleich erkennen, zu welchem Modul die 
Variablen gehören (falls das nicht auch schon aus dem Namen der 
Variablen ersichtlich ist).
Die entsprechenden Templates für die *.h und *.c Dateien lassen ich mir 
von der IDE (Eclipse) erzeugen.

[Stefan W. (dl6dx)]

Josef D. schrieb:
> Deshalb verwendet man besser in jeder Datei einen eindeutigen Namen,

Aber ja. Volle Zustimmung!

Grüße

Stefan

[dotm (Gast)]

Zum Teufel!!
Das ist doch abstrus! Erstmal ein Auszug aus dem Code:

config.c:

#define CREATEVAR
#include "PAC20_config.h"

USART_TypeDef* COM_USART[COMn] =
{
MODEM_PORT
};

config.h

#define COMn  1

typedef enum
  {
  MODEM = 0,
} COM_TypeDef;

#define MODEM_PORT                   USART1
  
#ifndef CREATEVAR
extern USART_TypeDef* COM_USART;
#endif

modem.c

#include "config.h"

void ModemInit(COM_TypeDef COM)
  {
  USART_Cmd(COM_USART[COM], ENABLE); //Fehler!
  }

So! der Compiler sagt aber bei ModemInit (die Zeile wo ich Fehler dazu 
geschrieben hab):

error:  #167: argument of type "USART_TypeDef" is incompatible with 
parameter of type "USART_TypeDef *"

Was zum Teufel ist da falsch?
Ich rufe ModemInit so auf:
ModemInit(MODEM);
die enum löst modemInit mit MODEM = 0 auf.
COM_USART ist ein Array aus Pointern und an Stelle Null steht MODEM_PORT 
also USART1
Wo denk ich da fehlerhaft? Ein virtuelles wiener Schnitzel für 
denjenigen der mir da weiterhelfen kann.

[Stefan E. (sternst)]

dotm schrieb:
> Was zum Teufel ist da falsch?

extern USART_TypeDef* COM_USART;

->

extern USART_TypeDef* COM_USART[];

Das "CREATEVAR" ist hier nicht nur überflüssig, sondern sogar 
kontraproduktiv. Ohne dem hätte der Compiler dir beim Übersetzen von 
config.c gleich gesagt, dass da zwei COM_USART mit inkompatiblen Typen 
sind.

[dotm (Gast)]

@stefan
für dich:
http://www.figlmueller.at/files/figlmueller/test/startbg.jpg


Klaro ein array ist ja ein pointer!

[dotm (Gast)]

Ok! Wer möchte sich ein weiteres Schnitzel verdienen?
Das Rennt jetzt alles so wie es soll, einzig allein bei

GPIO_InitStructure.GPIO_Speed = DIGITAL_OUT_SPEED[DIGITAL_OUT];

bekomm ich die Warning:

 warning:  #188-D: enumerated type mixed with another type

Zuerst hatte ich:

uint8_t DIGITAL_OUT_SPEED[DIGITAL_OUTn] =
{
  EN_FILTER_GPIO_SPEED, EN_MODEM_GPIO_SPEED, EN_SENSOR_GPIO_SPEED, N_RELAIS_GPIO_SPEED, SW_RELAIS_ON_GPIO_SPEED, SW_RELAIS_OFF_GPIO_SPEED, LED_GPIO_SPEED
};

wobei jeder Eintrag aus sowas besteht:

#define SW_RELAIS_OFF_GPIO_SPEED  GPIO_Speed_2MHz

unit8_t weil das folgendermassen aufgelöst wird:
stmf37x_gpio.h:

#define GPIO_Speed_10MHz GPIO_Speed_Level_1   /*!< Fast Speed:10MHz   */
#define GPIO_Speed_2MHz  GPIO_Speed_Level_2   /*!< Medium Speed:2MHz  */
#define GPIO_Speed_50MHz GPIO_Speed_Level_3   /*!< High Speed:50MHz   */

und im Endeffekt auch stm32f37x_gpio.h:

typedef enum
{
  GPIO_Speed_Level_1  = 0x01, /*!< Medium Speed */
  GPIO_Speed_Level_2  = 0x02, /*!< Fast Speed   */
  GPIO_Speed_Level_3  = 0x03  /*!< High Speed   */
}GPIOSpeed_TypeDef;

mein Versuch das Ganze dann so umzuschreiben:

GPIOSpeed_TypeDef DIGITAL_OUT_SPEED[DIGITAL_OUTn] =
{
  EN_FILTER_GPIO_SPEED, EN_MODEM_GPIO_SPEED, EN_SENSOR_GPIO_SPEED, N_RELAIS_GPIO_SPEED, SW_RELAIS_ON_GPIO_SPEED, SW_RELAIS_OFF_GPIO_SPEED, LED_GPIO_SPEED
};

oder auch

GPIOSpeed_TypeDef* DIGITAL_OUT_SPEED[DIGITAL_OUTn] =
{
  EN_FILTER_GPIO_SPEED, EN_MODEM_GPIO_SPEED, EN_SENSOR_GPIO_SPEED, N_RELAIS_GPIO_SPEED, SW_RELAIS_ON_GPIO_SPEED, SW_RELAIS_OFF_GPIO_SPEED, LED_GPIO_SPEED
};

fruchtet nicht (gleiche Warning ! - ??). Was gehört denn da jetzt rein 
und was will mir denn die Warning sagen?

[dotm (Gast)]

AHOI! hat sich erledigt (hatt vergessen das bei extern auch noch 
umzuschreiben). Schönen Abend!

[Mark B. (markbrandis)]

DIGITAL_OUT_SPEED

Das ist von der Nomenklatur her eine Konstante, hier aber der Name eines 
Arrays. Funktioniert latürnich, ist aber nicht schön ;-)

Edit: Ach so, hat Rufus Τ. Firefly ja schon geschrieben.