Hallo,
ich muss ein C Projekt, welches eigentlich auf Windows entwickelt wurde,
zu Linux portieren, der benutzte Compiler ist GCC.
Dort kann der Compiler aber die Dateien nicht finden, da die Header
Dateien öfters auf folgender Weise eingefügt wurden:
1. #include "Abc.h", der richtige Dateiname ist aber klein geschrieben (
abc.h )
2. #include "..\src\abc.h", der umgekehrte Schrägstrich wird aber in
Linux nicht unterstützt.
Ich kann(sollte) den Sourcecode so wenig wie möglich ändern, da das
Projekt auf Windows immer noch weiterentwickelt wird, und ich dann bei
jeder neuen Version alles nochmal ändern müsste.
Weiss vielleicht jemand von einer Compiler Option o.ä., mit der ich
dieses Problem umgehen kann?
Sorry wenn es zu diesen Thema schon einen Thread gibt, habe lange danach
gegoogelt.
Jerome
Du must die include verzeichnisse, di emit den Headern als parameter an
gcc übergeben. für Linux: -I./include für Windows:-I.\include. Das
machst du für alle verzeichnisse, in denen .h Dateien liegen.
du kannst gcc auch merere übergeben.
Da scheint mir ein automatischer Sourcecodekonverter, der alle eine
#include-Anweisung enthaltenden Zeilen behandelt, ein gangbarer Weg.
Das sollte mit per regex ausdrückbaren Regeln mit einem Werkzeug wie
sed machbar sein:
* Behandle nur Zeilen, die mit #include beginnen
* Ersetze in diesen jedes \ durch /
* Wandle in diesen alles in Kleinbuchstaben
Diesen Konverter-Mechanismus kannst Du per makefile vor dem eigentlichen
Compilerdurchlauf aufrufen.
1.: C ist Case sensitiv.
2.: Das Verhalten ist laut C Standard undefiniert, wenn im Header Namen
"\" auftaucht. Gleiches gilt für "//", "'" und "/*".
Du solltest die anderen Programmierer also überreden, sich an den C
Standard zu halten!
..sinnvoller als das jedes Mal aufs Neue wieder zu erledigen wäre es,
'das Original' (einmalig) zu korrigieren. Frag doch mal, ob Du das für
sie übernehmen darfst, mit etwas Geschick könnte sich das auf einige
Zeilen Bash und ein paar Aufrufe selbiger beschränken. Anschließend das
Projekt wieder 'zurückgeben'..
HTH
Die sinnigste Lösung wäre m.E. ebenfalls, die Namen in
einer irgendwie sinnvollen Weise zu schreiben und die
Quelltexte einmalig entsprechend anzupassen.
Falls das wirklich nicht geht, fallen mir noch folgende Varianten
ein:
1. Den Headerdateien ihre Namen zu lassen, und für alle
vorkommenden anderen Schreibweisen symbolische Links
auf die Dateien anlegen.
Beispiel:
Es gebe die Datei abc.h und #includes für abc.h, Abc.h und
ABC.h. Dann macht man einfach symLinks Abc.h und ABC.h, die
auf die Datei abc.h zeigen.
Das geht, indem man in das passende Verzeichnis geht und
dort eingibt:
1
ln -s abc.h Abc.h ABC.h
2. Je nach Dateisystem (ich glaube für die FAT-Varianten und
für NTFS) gibt es eine Option beim Mounten, aufgrund der
Groß-/Kleinschreibung ignoriert wird.
D.h. man könnte zumindest den Dateibaum, in dem die
Headerdateien liegen, damit mounten.
> 1.: C ist Case sensitiv.
C ja, aber C schreibt nicht vor, wie das Dateisystem mit Dateinamen
umzugehen hat; C weiß überhaupt nicht, was Dateien oder Dateinamen sind.
Was den zweiten Punkt des Pfadtrenners angeht, so ist es eine reichlich
autistische Sichtweise, ein verbreitetes Betriebssystem hartnäckig zu
ignorieren, auch wenn das Betriebssystem noch so unbeliebt sein mag. Es
existiert, und es wird in absehbarer Zeit auch keinen Abgang machen.
Sinnvolle Präprozessoren sind in der Lage, einfach mit beiden
Schreibweisen umzugehen, ohne Rücksicht auf ihr Wirtsbetriebssystem
nehmen zu müssen.
Und wenn die Unterscheidung von Groß- und Kleinschreibung in Dateinamen
auch noch so schick sein mag, hat es wirklich einen Sinn, daß blafusel
und BLAFUSEL zwei unterschiedliche Dateien sein können? Gibt es eine
wirklich ernstzunehmende Anwendung davon (abgesehen von der reichlich
verkorksten Konvention, daß .C C++- und .c C-Quelltext kennzeichnen
soll)?
Nein. Auch das scheint nur bewusst politisch gehaltene Inkompatilität zu
anderen Systemen zu sein.
Es gibt übrigens unixoide Betriebssysteme, deren Dateisysteme
standardmäßig nicht zwischen Groß- und Kleinschreibung unterscheiden:
Gibt es einen triftigen Grund, Groß-/Kleinschreibung zu ignorieren?
Rufus t. Firefly schrieb:
> Nein. Auch das scheint nur bewusst politisch gehaltene Inkompatilität zu> anderen Systemen zu sein.
das mag sein, aber offenbar seitens Microsoft.
Unix hatte seine Variante mit der Unterscheidung schon vor FAT.
Edit: .. und ist zudem flexibler, je nach Dateisystem kann es auch
Gro-ß/Kleinschreibung ignorieren.
Und so drehen wir uns im Kreis.
Wenn es unterschiedliche Standpunkte bei einem Problem gibt, dann gibt
es zwei Herangehensweisen, um das Problem zu lösen:
a) man beharrt unbeweglich auf seinem Standpunkt und wirft der
Gegenseite ihren Fehler vor
b) man trifft sich in der Mitte und sucht einen gemeinsamen Nenner
Da MS-Dateisysteme seit einigen Jahren immerhin die Groß- und
Kleinschreibung zwar nicht unterscheiden, aber speichern, hat sich hier
MS wenigstens ein Futzelchen bewegt.
(Genauer: Davor hatte MS gar keine Dateinamen, sondern nur recht
nutzlose 8.3-Kürzel).
Übrigens haben vor MS auch andere Betriebssysteme keine Unterschiede in
Groß/Kleinschreibung bei Dateinamen gekannt, das ist also keine
"Erfindung" von MS.
> Gibt es einen triftigen Grund, Groß-/Kleinschreibung zu ignorieren?
Das beantwortet meine Frage nicht. Existiert eine Anwendung, bei der
gleichzeitig Dateien gleichen Namens, aber unterschiedlicher
Schreibweise genutzt werden? Was gewinnt man dadurch, außer potentieller
Verwirrung?
[Nachtrag:
Das von mir als "unixoid" titulierte Betriebssystme ist sogar ein echtes
Unix, basierend auf BSD]
Genaugenommen redet ihr euch im Kreis drehend am
Case-Sensitivitäts-Problem vorbei: Das Problem ist, dass
1. Ein Entwickler eine Datei anlegt, die er 'Grützewütze' nennt
2. Er (oder jemand anders, das ist unerheblich) selbige Datei verwenden
möchte, im Quellcode selbige aber mit 'GrÜtZeWüTzWe' referenziert
3. ★zufälligerweise★ das Betriebssystem die beiden Namen auf die selbe
Datei abbildet.
Die (einzig richtige) Lösung ist, die Dateien genauso zu benennen wie
man sie referenziert (oder umgekehrt), alles andere ist und bleibt
Murks. Und Murks ist dazu da behoben zu werden.
Nix für ungut
Dazu noch eins: Da der Backslash für alle Unix-Abkömmlinge ein normaler
Bestandteil des Dateinamens ist, ist:
#include "..\src\abc.h"
ein Dateiname ohne jegliche Subdirectories, nicht anders zu
interpretieren als
1
"___src_abc.h"
Es ist nicht möglich, daraus nachträglich einen Pfad mit
Subdirectories zu machen außer durch Konversion der Quelldateien. Auch
mit -I-Anweisungen allein ist da nichts zu machen.
Rufus t. Firefly schrieb:
> Was den zweiten Punkt des Pfadtrenners angeht, so ist es eine reichlich> autistische Sichtweise, ein verbreitetes Betriebssystem hartnäckig zu> ignorieren, auch wenn das Betriebssystem noch so unbeliebt sein mag. Es> existiert, und es wird in absehbarer Zeit auch keinen Abgang machen.
Und die Abhilfe soll sein, daß man an einer einzelnen ganz spezifischen
Stelle das verhalten dieses anderen Systems emuliert und sich dadurch
anders verhält, als es auf dem lokalen System an sämtlichen anderen
Stellen üblich wäre ('\' ist das Escape-Zeichen)?
> Sinnvolle Präprozessoren sind in der Lage, einfach mit beiden> Schreibweisen umzugehen, ohne Rücksicht auf ihr Wirtsbetriebssystem> nehmen zu müssen.
Es gibt auch noch andere Systeme mit völlig anderen Verzeichnistrennern.
Ich habe auch schon mit VMS gearbeitet. Da sehen Pfade komplett anders
aus. (*) Muß das dann auch unterstützt werden oder ist das System zu
unwichtig (nach welchem Kriterium?) um davon unterstützt zu werden?
> Und wenn die Unterscheidung von Groß- und Kleinschreibung in Dateinamen> auch noch so schick sein mag, hat es wirklich einen Sinn, daß blafusel> und BLAFUSEL zwei unterschiedliche Dateien sein können?
Hat es denn irgendeinen Nachteil?
Es ist zumindest deutlich einfacher zu handhaben. Bei ASCII ist es ja
noch einfach, aber sobald du mit Unicode arbeitest, wird es kompliziert.
("maße" == "MASSE" == "masse"?)
> Gibt es eine wirklich ernstzunehmende Anwendung davon (abgesehen von> der reichlich verkorksten Konvention, daß .C C++- und .c C-Quelltext> kennzeichnen soll)?
Ich sehe in der Konvention kein wirkliches Problem, wenn man nicht mit
einem System arbeiten muß, das das nicht richtig unterscheiden kann.
> Nein. Auch das scheint nur bewusst politisch gehaltene Inkompatilität> zu anderen Systemen zu sein.
Das ist doch Unsinn. Die case-sensitiven Dateinahmen hatte Unix schon in
einer Zeit lange bevor es das System gab, zu dem es deiner Behauptung
nach bewusst inkompatibel sein soll. Letztendlich ist deshalb auch C
case-sensitiv. Das war dort, wo es herkam, einfach so üblich.
Ich sehe auch keinen wirklichen Vorteil, das jetzt nachträglich zu
ändern, nur um sich an andere Systeme anzupassen und deren "bewusst
politisch gehaltene Inkompatilität" zu umgehen.
(*) für Interessierte:
http://de.wikipedia.org/wiki/Virtual_Memory_System#Merkmale
Das war nicht als Angriff auf Windows gedacht. Aber / ist per Definition
das Zeichen für Pfadtrenner in C. Je nach Betriebssystem wird es dann
halt vom Präprozessor ersetzt. Und die Tatsache, dass es Betriebssysteme
gibt, die zwischen Groß- und Kleinschreibung unterscheiden, macht es aus
meiner Sicht sinnvoll, dass dies auch von C unterstützt wird.
Noch blöder wäre es doch, wenn für jedes Betriebssystem ein eigener C
Standard existieren würde. Das ist doch letztendlich auch nur eine
Konvention, die die Portierbarkeit erhöhen soll.
Ansonsten kann ich nur empfehlen, in Dateinamen von C-Quelltext
ausschließlich ASCII Kleinbuchstaben und den Unterstrich _ zu verwenden
und zwar mit den Endungen .c für C, .cpp für C++ und .h für Header
Dateien. Eventuell die Endung .hpp für C++ Header.
Daniel Heydemann schrieb:
> Aber / ist per Definition> das Zeichen für Pfadtrenner in C.
Wo hast du diese Definition denn her?
Alle Headerdateien, auf die sich der C-Standard bezieht, kommen
ohne Pfadnamenskomponenten aus.
> Je nach Betriebssystem wird es dann> halt vom Präprozessor ersetzt.
Kann sein, dass manche Compiler (VMS?) das tun, aber im Falle von
Windows ist es einfach das Betriebssystem selbst, das den
Vorwärtsschrägstrich als Pfadnamentrenner versteht -- parallel zum
Rückwärtsschrägstrich, und das schon seit mindestens MS-DOS 3.30
(vermutlich noch früher). Lediglich die Kommandozeilenverarbeitung
(command.com bzw. cmd.exe) kommen damit nicht klar, weil sie von
CP/M die Vorwärtsschrägstriche mal als Optionstrenner geerbt haben.
Da aber praktisch alle derzeit in Benutzung befindlichen
Betriebssysteme mit dem Vorwärtsschrägstrich klar kommen, gibt es in
der Tat keinen Grund, ihn nicht zu benutzen an den Stellen, wo das bei
#include notwendig sein sollte. Da die Windows-Dateisysteme
heutzutage außerdem gar nicht so "case insensitive" sind, wie immer
behauptet (*), sollte man außerdem für maximale Portabilität darauf
achten, dass die Schreibweise des Dateinamens bei #include genauso ist
wie die, mit der die Datei im Dateisystem tatsächlich angelegt worden
ist. (Jeweils alles in Kleinbuchstaben zu halten ist natürlich der
einfachste Lösungsansatz dafür, aber nicht der einzige.)
(*) Alle derzeitigen Dateisysteme auch unter Windows können sehr wohl
Groß- und Kleinbuchstaben im Dateinamen selbst unterscheiden.
Lediglich die Suchfunktionen sind so implementiert, dass sie danach
nicht mehr unterscheiden, was zur Folge hat, dass die Groß-/
Kleinschreibung eines Dateinamens ausschließlich beim Anlegen
festgelegt werden kann und dann "in Stein gemeißelt" ist. Wenn man
die Datei hinterher umbenennen möchte und dabei lediglich die Groß-/
Kleinschreibung ändern will, wird dies natürlich abgelehnt, weil ja
vermeintlich der Zielname bereits existiert.
> und zwar mit den Endungen .c für C, .cpp für C++ und .h für Header> Dateien. Eventuell die Endung .hpp für C++ Header.
Huh. :-) Andere Leute schwören auf .cc oder .cxx für C++-Dateien. ;-)
(OK, Leute, bei denen nicht nur das Dateisystem sondern auch das
Betriebssystem case sensitive arbeitet, nehmen dann auch noch .C
dafür...)
Einen Sinn in .hpp (oder .hxx) sehe ich überhaupt nicht. C++ scheint
ja mittlerweile komplett die Dateinamenssuffixe außen vor lassen zu
wollen und benutzt nur noch #include <iostream> etc.
JTC1/SC22/WG14 N843 (Draft C99 Standard, der Standard selbst ist nicht
frei verfügbar):
6.4.7 Header names
[#3] If the characters ', \, ", //, or /* occur in the
sequence between the < and > delimiters, the behavior is
undefined. Similarly, if the characters ', \, //, or /*
occur in the sequence between the " delimiters, the behavior
is undefined.56) A header name preprocessing token is
recognized only within a #include preprocessing directive.
Der gleiche Spruch steht ohne // schon bei ANSI C.
Also hat \ in Header-Dateinamen nicht verloren, auch wenn es zufällig
bei einem bestimmten Compiler unter einem bestimmeten Betriebssystem
damit funktioniert.
Jörg Wunsch schrieb:
> Wo hast du diese Definition denn her?> ...> Kann sein, dass manche Compiler (VMS?) das tun, aber im Falle von [...]
Manche Compiler ist etwas unter trieben, die meisten trifft es eher. Es
ist also eine "Quasi-Standard". Was aber auch nichts daran ändert, dass
in ISO/IEC 9899:1999 folgendes steht: "If the characters ', \, ", //, or
/* occur in the sequence between the < and > delimiters,
the behavior is undefined."
> Huh. :-) Andere Leute schwören auf .cc oder .cxx für C++-Dateien. ;-)
Nun, das muss ich ja aber nicht empfehlen... ;-)
>> Einen Sinn in .hpp (oder .hxx) sehe ich überhaupt nicht.
Das habe ich früher benutzt, damit emacs die Header im C++ Mode öffnet.
Daniel Heydemann schrieb:
> Das habe ich früher benutzt, damit emacs die Header im C++ Mode öffnet.
Guter Punkt, aber dafür tun es auch diese Zeilen am Ende der Datei:
Daniel Heydemann schrieb:
>> Kann sein, dass manche Compiler (VMS?) das tun, aber im Falle von [...]> Manche Compiler ist etwas unter trieben, die meisten trifft es eher.
Zeig mir bitte ein Beispiel. Zur Erinnerung, der Kontext dazu (den
du falsch zitiert hast) war, dass der Präprozessor da irgendwas
ersetzen würde. Das glaube ich dir so einfach nicht, also zumindest
nicht für MacOS, alle Arten von Unix oder Windows.
> Was aber auch nichts daran ändert, dass> in ISO/IEC 9899:1999 folgendes steht: "If the characters ', \, ", //, or> /* occur in the sequence between the < and > delimiters,> the behavior is undefined."
Das beschreibt allerdings nicht, das Vorwärtsstriche vom C-Standard
als Pfadnamentrenner definiert wären (wie du behauptet hast),
sondern das besagt nur, dass Rückwärtsschrägstriche ausdrücklich als
unportabel ausgeschlossen sind, was natürlich Sinn hat, weil man auf
diese Weise dem Compiler überlässt, wann er Dinge wie \t bewertet, wie
sie beispielsweise bei
Rolf Magnus schrieb:
> Hat es denn irgendeinen Nachteil?
Es ist voellig unnatuerlich. Ich hatte mal einen Kollegen, der meinte
auch immer, das sei die einzig richtige Variante, weil sein Unix das
schon immer so gemacht hat. Der Groschen fiel, als er seiner Mutter am
Telefon mal einen langen Pfad diktieren musste, der reichlich
Gross-/kleinschreibung verwendet hat. Einfach Erkenntnis: Nur die
Schriftsprache kennt die Gross-/kleinschreibung und sie hat praktisch
keine syntaktische Bedeutung. Nicht umsonst haben es die meisten Systeme
schon immer anders gemacht. Windows ist da eher ein Spaetling, die haben
das Problem halt frueher umgangen, indem sie nur Grosschreibung
verwendet haben, als andere Systeme das laengst richtig gemacht haben.
Wenn hier im Forum jemand ohne Umschalttaste schreibt, dann ist das
m.M.n. recht unnatürlich.
Es rührt vielleicht auch daher, dass simple Byteweise-Vergleiche
einfacher und schneller sind, als Vergleiche ohne Beachtung von Groß-
und Kleinschreibung. Es gibt ja auch noch Unicode.
Was passiert, wenn bei Microsoft eine Lampe kaputt geht?
Die anderen werden auch alle zerschlagen, und die
Dunkelheit wird zum Industriestandard erklärt!
Jörg Wunsch schrieb:
> Zeig mir bitte ein Beispiel. Zur Erinnerung, der Kontext dazu (den> du falsch zitiert hast) war, dass der Präprozessor da irgendwas> ersetzen würde. Das glaube ich dir so einfach nicht, also zumindest> nicht für MacOS, alle Arten von Unix oder Windows.
Intern muss es der Präprozessor sehr wohl ersetzen, da er ja die Dateien
finden und einsetzen muss.
> Das beschreibt allerdings nicht, das Vorwärtsstriche vom C-Standard> als Pfadnamentrenner definiert wären (wie du behauptet hast),
Da hast Du vollkommen recht, mein Fehler. Aber als "quasi" bzw. "de
facto" Standard wird es von vielen Compilern/Präprozessoren verstanden.
Zumindest fallen mir spontan µVision, Keil, cpp und MSVC ein.
Daniel Heydemann schrieb:
> Intern muss es der Präprozessor sehr wohl ersetzen, da er ja die Dateien> finden und einsetzen muss.
Nein. Du hast meinen Beitrag oben entweder nicht gelesen oder
nicht verstanden:
Beitrag "Re: Header Dateien Groß/Kleinschreibung"Windows selbst kommt mit den Vorwärtsschrägstrichen zurecht. Der
Präprozessor macht weiter nichts als ein
Jörg Wunsch schrieb:
> Nein. Du hast meinen Beitrag oben entweder nicht gelesen oder> nicht verstanden:
Nicht richtig gelesen. Ich dachte immer, dass Windows den Schrägstrich
in Pfadangaben erst ab Windows 2000 unterstützt. Also kein Wunder, dass
auch die ganzen Compiler vor W2k mit dem Schrägstrich zurecht gekommen
sind. Und wenn der Schrägstrich nativ unterstützt wird muss natürlich
auch nichts ersetzt werden. Die Vorstellung der Schrägstrich sei ein
(Verabredeter) Standard ist dann obsolet, vielmehr entspringt sie der
Erfahrung, dass alle C-Compiler unter Linux, DOS und Windows, mit denen
man je gearbeitet hat, ihn scheinbar unterstützen. Scheinbar deswegen,
weil ihn in Wirklichkeit schon DOS 3.x nativ unterstützte.
Daniel Heydemann schrieb:
> Die Vorstellung der Schrägstrich sei ein> (Verabredeter) Standard ist dann obsolet,
Wobei: Ganz so unrecht hast du nicht.
Mit einem / ist man oft auf der sicheren Seite, viele Präprozessoren
erkennen das tatsächlich. So zb viele der C-Compiler, die für das oben
angesprochene VMS gebaut wurden, bei dem die Directorysyntax ja völlig
anders aussieht
Fazit: Mit einem / kann man erst mal nicht viel falsch machen. Mit ein
bischen Glück funktioniert er auf den interessierenden Compilern. Wenn
nicht, muss man auf die native Syntax des BS ausweichen.
Von daher kann der Rat an den TO nur lauten:
Versuch nicht, das mittels irgendwelcher Werkzeuge zu korrigieren,
sondern bring die Originalentwickler dazu, die Syntax im Original
anzupassen. Das kostet ihnen nichts, bringt keine Nachteile und erspart
eine Fehlerquelle bei der Portierung.
Wenn die Entwickler Profis sind, dann MUSS ihre Antwort lauten:
Oh. Das haben wir übersehen. Danke für den Hinweis
und sie werden das ändern.
Karl heinz Buchegger schrieb:
> Wenn die Entwickler Profis sind, dann MUSS ihre Antwort lauten:> Oh. Das haben wir übersehen. Danke für den Hinweis> und sie werden das ändern.
Du bist ja ein Zyniker... :-/
Was mir noch auffällt:
Christian J. schrieb:
> Du must die include verzeichnisse, di emit den Headern als parameter an> gcc übergeben. für Linux: -I./include für Windows:-I.\include. Das> machst du für alle verzeichnisse, in denen .h Dateien liegen.>> du kannst gcc auch merere übergeben.>
1
gcc-I.\include-I.\include2-I.\include3...
Das wird unter gängigen Shells sowieso in die Hose gehen. Bestenfalls
wird der gcc dann nach '.include', '.include2' und '.include3' suchen.
Peter Stegemann schrieb:
> Karl heinz Buchegger schrieb:>>> Wenn die Entwickler Profis sind, dann MUSS ihre Antwort lauten:>> Oh. Das haben wir übersehen. Danke für den Hinweis>> und sie werden das ändern.>> Du bist ja ein Zyniker... :-/
:-)
So war das gar nicht gemeint. Ehrlich!
Worauf ich hinaus wollte:
Keine Hemmungen, wenn man zu den Profis geht und sie um diese Änderung
bittet. Das ist für die Originalprogrammierer ein Klacks und tut nicht
weh. Da muss kein Bugreport geschrieben werden oder eine
Entwicklersitzung einberufen werden oder dergleichen.
Streubt sich jemand gegen eine derartige Änderung, dann ist er ein
bornierter Stubenhocker, der noch nie ein Programm von A nach B portiert
hat. Da warten noch ganz andere Probleme. Dagegen ist das hier ein
'Lercherlschas'
Vielen Dank für die Antworten. Anscheinend gibt es keine andere Lösung
als das Programm zu ändern. Ich hatte gehofft, es gibt irgendeine Option
im gcc, mit der man das Problem umgehen kann.
Karl heinz Buchegger schrieb:
> Keine Hemmungen, wenn man zu den Profis geht und sie um diese Änderung>> bittet. Das ist für die Originalprogrammierer ein Klacks und tut nicht>> weh. Da muss kein Bugreport geschrieben werden oder eine>> Entwicklersitzung einberufen werden oder dergleichen.
Das Problem ist, es handelt sich um ein Projekt mit insgesamt 467
Dateien.
Ich habe zwar schon ein Shellscript geschrieben, das die Änderungen
automatisch durchführt, aber allein das Überprüfen, ob Fehler ( durch
den Script) aufgetreten sind würde sehr sehr lange Dauern.
Da die Zielplattform ein Mikrocontroller ist, bin ich auf Windows in
Verbindung mit Cygwin umgestiegen, es klappt auch ganz gut.
Jörg Wunsch schrieb:
>> Was aber auch nichts daran ändert, dass>>> in ISO/IEC 9899:1999 folgendes steht: "If the characters ', \, ", //, or>>> /* occur in the sequence between the < and > delimiters,>>> the behavior is undefined."
Hätte der gcc Compiler in Windows von Anfang an bei falscher Einbindung
von Headern gemeckert, dann hätte ich das Problem jetzt nicht ...
jeromert schrieb:
> Ich habe zwar schon ein Shellscript geschrieben, das die Änderungen> automatisch durchführt, aber allein das Überprüfen, ob Fehler ( durch> den Script) aufgetreten sind würde sehr sehr lange Dauern.
Huh? Einmal die Ausgabe von »svn diff« reviewen um zu sehen, dass
sich nicht mehr als die #include-Zeilen geändert haben, wie lange
dauert das denn? Ich denke, dass man nach einer Stunde fertig sein
sollte.
darf nichts mehr ausgeben, wenn sich nur #include-Zeilen geändert
haben.
> Hätte der gcc Compiler in Windows von Anfang an bei falscher Einbindung> von Headern gemeckert, dann hätte ich das Problem jetzt nicht ...
Schreib den GCC-Leuten einen Bugreport, dass sie das gemäß Standard
undefinierte Verhalten bitte warnen sollen. Ich denke, dass diese
Anforderung legitim ist, wenn das so im Standard geschrieben steht
(zumal dort "undefined" steht, nicht etwa "implementation-defined").
Thread beobachten
Seitenaufteilung abschalten