ich weiß leider nicht, wohin das richtigerweise gehört ...
Mein neuer Compiler (xlC/C++ V8.0 for AIX) moniert die Kombination von extern "C" und _System als "conflicting linkages" ...

extern "C" {
   int _System f();
}

int main() {
   return f();
}

=>

"main.cpp", line 2.16: 1540-1179 (S) "extern "C" int _System f()" contains conflicting linkages.
"main.cpp", line 6.11: 1540-0274 (S) The name lookup for "f" did not find a declaration.

dem alten Compiler (V5.0.2) war das noch egal...
Nervpunkt1: Nirgends in der Xlc-Doku oder der IBM-Homepage überhaupt finde ich _System beschrieben.

Nervpunkt2: Natürlich kann ich jetzt das _System einfach wegwerfen ... aber es ist eben der Header zu einer "Fremdlib" und da bin ich ein wenig unsicher, ob es nicht doch irgendeine Auswirkung hat. (besonders in Kombination, dass die lib aus nicht allzu vertrauenserweckender Hand kommt).

Weiß jemand, was _System unter AIX überhaupt bewirkt und warum sich das mit extern "C" beißen soll ?

Gruß,

Simon2.

Nervpunkt1: Nirgends in der Xlc-Doku oder der IBM-Homepage überhaupt finde ich _System beschrieben.

Bezeichner mit führendem doppelten Unterstrich oder führendem einfachem Unterstrich und folgendem Großbuchstaben sind für den Compiler reserviert, siehe ISO 14882 § 17.4.3.1.2.

Bezeichner mit führendem Unterstrich sind im globalen Namensraum reserviert. In anderen Namensräumen darf man Unterstrich mit Kleinbuchstaben verwenden.

Tip: Bezeichner mit führendem Unterstrich(en) gar nicht verwenden.

Simon2 schrieb:

Nervpunkt2: Natürlich kann ich jetzt das _System einfach wegwerfen ... aber es ist eben der Header zu einer "Fremdlib" und da bin ich ein wenig unsicher, ob es nicht doch irgendeine Auswirkung hat. (besonders in Kombination, dass die lib aus nicht allzu vertrauenserweckender Hand kommt).

Bugreport an der Autoren der Lib, das muß behoben werden.

Simon2 schrieb:

Nervpunkt1: Nirgends in der Xlc-Doku oder der IBM-Homepage überhaupt finde ich _System beschrieben.

Bezeichner mit führendem doppelten Unterstrich oder führendem einfachem Unterstrich und folgendem Großbuchstaben sind für den Compiler reserviert, siehe ISO 14882 § 17.4.3.1.2.

Bezeichner mit führendem Unterstrich sind im globalen Namensraum reserviert. In anderen Namensräumen darf man Unterstrich mit Kleinbuchstaben verwenden.

Tip: Bezeichner mit führendem Unterstrich(en) gar nicht verwenden.

Dort steht nicht Compiler sondern Implementation. Hier geht es gerade um eine systemspezifische Erweiterung, wozu also der Hinweis? Man könnte höchtens monieren, dass dies evtl. in einem anderen Unterforum (etwa Compiler- und IDE) besser aufgehoben wäre.

@OP: Soweit ich das verstehe, impliziert _System sowohl eine eigene Aufrufkonvention als auch ein eigenes Namemangling-Schema. Damit wird extern "C" tatsächlich überflüssig. Darin unterscheidet sich die Situation etwa zu einer Deklaration (Windows) wie extern "C" int __stdcall f(), da hier __stdcall keinen Einfluss auf das Namemangling hat. Am besten also das extern "C" weglassen, evtl. kann auch so etwas wie extern "SYSTEM" int f() funktionieren.

Simon2 schrieb:

Nervpunkt1: Nirgends in der Xlc-Doku oder der IBM-Homepage überhaupt finde ich _System beschrieben.

Bezeichner mit führendem doppelten Unterstrich oder führendem einfachem Unterstrich und folgendem Großbuchstaben sind für den Compiler reserviert, siehe ISO 14882 § 17.4.3.1.2....

Damit habe ich ja auch kein Problem - mehr damit, dass der Compilerhersteller nicht beschreibt, WAS er macht/wie er zu benutzen ist, aber Falschnutzung anmoniert...

~john schrieb:

Tip: Bezeichner mit führendem Unterstrich(en) gar nicht verwenden....

Ich glaube, es liegt hier ein Mißverständnis vor: Es geht hier nicht um eine "zufällige Doppelnutzung", sondern darum, dass ein spezielles Compilerfeature genutzt werden soll (nämlich eine calling convention namens "_System"), was sich aber anscheinend in der neuesten Version mit extern "C" beißt.

~john schrieb:

...Bugreport an der Autoren der Lib, das muß behoben werden.

Tja, das sind Leute bei uns aus dem Haus, die nie Zeit (und leider nicht so gaaaanz viel Ahnung) haben... letztlich bin ich auf jeden Fall schneller damit, wenn ich selbst rausbekomme, ob sie diese calling convention in diesem speziellen Fall brauchen oder nicht.

Gruß,

Simon2.

Ich würde eher das extern "C" weglassen als das _System. Der Compiler ist hoffentlich schlau genug zu wissen, wie er Systemfunktionen aufrufen soll.

camper schrieb:

...Am besten also das extern "C" weglassen, ...

Tja, das war auch mein erster Gedanke ... leider bekomme ich so trotzdem eine "undefined symbols"-Fehlermeldung vom Linker. Das Namemangeling wird anscheinend vom _System nicht unterdrückt.

camper schrieb:

...evtl. kann auch so etwas wie extern "SYSTEM" int f() funktionieren. ...

Also Compile und Link laufen so tadellos - leider ist diese convention auch nicht besser dokumentiert als _System (= überhaupt nicht). Ich weiß also leider nicht, ob Folgendes wirklich kompatibel ist:

// module.c
int _System f() { return 0; }

// main.cpp
extern "SYSTEM" {
   int f();
}

int main() { return f(); }

... und ob das eine Verbesserung ist ggü.:

// main.cpp
extern "C" {
   int f();
}

Immerhin erkennt der Compiler das "SYSTEM" (ein hier angefügtes "SIMON2" lieferte die lustige Warning:

"main.cpp", line 1.8: 1540-0523 (W) Linkage "SIMON2" is not known. extern "C" is assumed.

Mein Problem ist ja nicht nur, dass ich es irgendwie kompiliert und gelinkt haben will, sondern es sollte schon richtig passen - also auch bei längerer Laufzeit, Multithreading, ... (ist Teil eines Servers) garantiert das Richtige machen und keine Speicherlecks, zugriffsfehler, o.ä. produzieren ...

Gruß,

Simon2.

Ich glaube, es liegt hier ein Mißverständnis vor: Es geht hier nicht um eine "zufällige Doppelnutzung", sondern darum, dass ein spezielles Compilerfeature genutzt werden soll (nämlich eine calling convention namens "_System"), was sich aber anscheinend in der neuesten Version mit extern "C" beißt.

Nicht ohne Grund sind Bezeichner dieser Art für die Implementation reserviert. Wenn es keinen ganz triftigen Grund (Kernel Module, etc.) gibt, in der Implementation herumzuwurschteln, dann nimmt man insbesondere auf einem UNIX (naja AIX) nur extern "C". Dir ist schon aufgefallen, daß das ganze von IBM gar nicht dokumentiert ist. Also, Finger weg davon, und ohne das probieren.

Simon2 schrieb:

Tja, das sind Leute bei uns aus dem Haus, die nie Zeit (und leider nicht so gaaaanz viel Ahnung) haben...

Wenn man irgend welche Compiler spezifischen Dinge nutzt, dann sollte man das wenigstens per bedingte Compilierung absichern und dokumentieren. Scheint nicht der Fall zu sein. Notfalls nachfragen was das soll.

...

Simon2 schrieb:

Tja, das sind Leute bei uns aus dem Haus, die nie Zeit (und leider nicht so gaaaanz viel Ahnung) haben...

Wenn man irgend welche Compiler spezifischen Dinge nutzt, dann sollte man das wenigstens per bedingte Compilierung absichern und dokumentieren. Scheint nicht der Fall zu sein. ...

Doch, das haben sie schon getan (über ein entsprechendes #ifdef) und offensichtlich sprechen sie da ja ein nutzbares Feature an - im Augenblick gehe ich nur davon aus, dass ich zu blöd bin, eine entsprechende Doku zu finden.
Der Fall ist äquivalent zu _LINE_, _FILE_, ... auch compilerspezifisch und trotzdem darf man die nutzen - und die sind leider auch eher sparsam dokumentiert...

Also suche ich überall nach Infos ... eben auch hier.

Gruß,

Simon2.

Doch, das haben sie schon getan (über ein entsprechendes #ifdef) und offensichtlich sprechen sie da ja ein nutzbares Feature an - im Augenblick gehe ich nur davon aus, dass ich zu blöd bin, eine entsprechende Doku zu finden.

"offensichtlich"? Das Symbol "_System" wird nicht in der ISO C noch C++ Norm definiert. Wenn es weder im C oder C++-Compilerhandbuch noch im Linker Handbuch auftaucht, dann stellt sich die Frage warum das überhaupt verwendet wurde. Möglicherweise findet sich etwas in der Compiler Doku zu dem alten Compiler.

Simon2 schrieb:

Der Fall ist äquivalent zu _LINE_, _FILE_,

Dem ist nicht so. Denn die Bedeutung von __LINE__, __FILE__ wird in der ISO C Norm definiert.