www.mikrocontroller.net

Forum: Compiler & IDEs Header Dateien Groß/Kleinschreibung


Autor: jeromert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian J. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
gcc -I.\include -I.\include2 -I.\include3 ...

Ich hoffe du verstehst wie ich das meine.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Daniel Heydemann (dl7vkj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
..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

Autor: Link zu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohm, was spricht gegen [1] "Tabelle 12.4   Konstanten für bestimmte 
Betriebssysteme"?

[1] http://www.win-tux.de/c_012_002.htm#RxxobKap012002...

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
     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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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:
Last login: Tue Feb  9 21:45:26 on ttys000
macbook:~ rufus$ pwd
/Users/rufus
macbook:~ rufus$ mkdir bla
macbook:~ rufus$ mkdir Bla
mkdir: Bla: File exists
macbook:~ rufus$ cd Bla
macbook:Bla rufus$ 

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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]

Autor: g457 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hc Zimmerer (mizch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
"___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.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
und zur Entspannung:
die Schreibweise mit / also:
#include <avr/io.h>
ist per Definition portabel, sie funktioniert auf jedem
System und ist eindeutig die empfehlenswerte.

Autor: Rolf Magnus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Daniel Heydemann (dl7vkj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Juergen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Daniel Heydemann (dl7vkj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
// Local Variables:
// mode:C++
// End:

Dann kann die Datei heißen, wie sie will.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
#include <util\twi.h>

auftreten könnten.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus Wachtler (mfgkw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was passiert, wenn bei Microsoft eine Lampe kaputt geht?

Die anderen werden auch alle zerschlagen, und die
Dunkelheit wird zum Industriestandard erklärt!

Autor: Daniel Heydemann (dl7vkj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
 f = fopen("avr/io.h", "r");

...und die Datei wird: ganz einfach gefunden.

Autor: Daniel Heydemann (dl7vkj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: P. S. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... :-/

Autor: Sven P. (haku) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
>
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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'

Autor: jeromert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.
svn diff | grep '^[-+]' | grep -E -v '^((---)|([+][+][+])) ' | grep -v '#include'

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").

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.