<AltHerrenGemoppere>Die lassen heutzutage aber auch jeden durchkommen.</AlteHerrenRaus>
Gratulation!
<AltHerrenGemoppere>Die lassen heutzutage aber auch jeden durchkommen.</AlteHerrenRaus>
Ja.RobertDebiannutzer hat geschrieben:12.04.2019 13:50:28Denn byte order spielt ja nur dann eine Rolle, wenn wir Einheiten verwenden, die aus mehreren Bytes bestehen (also z.B. wchar_t, int, char16_t, char32_t).Meillo hat geschrieben:18.12.2018 22:53:50warum es UTF-16-LE und UTF-16-BE gibt, aber nur ein UTF-8
Nein, koennen wir nicht, denn: Wie gross waere denn die Einheit, die du lesen wuerdest, wenn du genau ein weiteres UTF-8-Zeichen *lesen* willst?Diese können wir aber im Prinzip ebenso für UTF-8 verwenden, wie für UTF-16/-32 (es würde nur wenig Sinn ergeben).
Aber welches der zwei UTF-16-Bytes speicherst du dann als erstes ab? Erst das niederwertige oder erst das hoeherwertige? Da diese Entscheidung frei ist, haben wir eben LE und BE.Genauso könnten wir (im Prinzip!) auch UTF-16 bzw. UTF-32 in einzelnen Bytes speichern (also als char-array in C).
Klasse, dass nun auch bewiesen ist, dass ich Recht habe. ;-P[...] wäre imho bewiesen, dass @meillo Recht hat, wenn er meint, dass UTF-8 das einzig wahre Encoding für das Unicode-Charset ist...
Vier Bytes - der Rest würde wie bei UTF-16/-32 mit '\0' aufgefüllt werden. (Macht natürlich keinen Sinn.)Meillo hat geschrieben:22.04.2019 08:59:49Wie gross waere denn die Einheit, die du lesen wuerdest, wenn du genau ein weiteres UTF-8-Zeichen *lesen* willst?
So könnte man ja (im Prinzip!) doch auch bei UTF-8 argumentieren, oder?Meillo hat geschrieben:22.04.2019 08:59:49Aber welches der zwei UTF-16-Bytes speicherst du dann als erstes ab? Erst das niederwertige oder erst das hoeherwertige? Da diese Entscheidung frei ist, haben wir eben LE und BE.
Ich hoffe, dass Du mich nicht falsch verstanden hast. Ich freue mich halt immer, wenn ich meine, dass auch ich zu tieferer Einsicht gekommen bin.Meillo hat geschrieben:22.04.2019 08:59:49Klasse, dass nun auch bewiesen ist, dass ich Recht habe. ;-P
Vorsicht, hier darfst du nicht schlampig sein, in deinen Ueberlegungen.RobertDebiannutzer hat geschrieben:22.04.2019 10:54:18Vier Bytes - der Rest würde wie bei UTF-16/-32 mit '\0' aufgefüllt werden. (Macht natürlich keinen Sinn.)Meillo hat geschrieben:22.04.2019 08:59:49Wie gross waere denn die Einheit, die du lesen wuerdest, wenn du genau ein weiteres UTF-8-Zeichen *lesen* willst?
Nein, in UTF-8 ist definiert wie die einzig moegliche Reihenfolge ist. UTF-8 kann man auch nur byteweise lesen und byteweises Lesen hat immer eine definierte Reihenfolge.So könnte man ja (im Prinzip!) doch auch bei UTF-8 argumentieren, oder?Meillo hat geschrieben:22.04.2019 08:59:49Aber welches der zwei UTF-16-Bytes speicherst du dann als erstes ab? Erst das niederwertige oder erst das hoeherwertige? Da diese Entscheidung frei ist, haben wir eben LE und BE.
Nee, nee, ich fand's nur lustig wie du das geschrieben hast. Wenn mir von nun an in irgendwelchen kontroversen Diskussionen irgendjemand mal widersprechen will, dann werde ich einfach darauf verweisen, dass du bewiesen hast, dass ich Recht habe. *hohoho* Danke dafuer!Ich hoffe, dass Du mich nicht falsch verstanden hast. Ich freue mich halt immer, wenn ich meine, dass auch ich zu tieferer Einsicht gekommen bin.Meillo hat geschrieben:22.04.2019 08:59:49Klasse, dass nun auch bewiesen ist, dass ich Recht habe. ;-P
Ja klar, sorry, da war ich vorher echt unkonzentriert...Meillo hat geschrieben:22.04.2019 11:17:39Bislang denkst du zu sehr in Datenstrukturen in der Programmiersprache. dort kannst du natuerlich irgendwas mit Nullen auffuellen, beim Lesen muss man anders denken, denn wenn du vier Bytes von Stdin gelesen hast, dann sind die dort weg. Wenn du nur ein Zeichen lesen wolltest und es waren vier, dann hast du mit den restlichen drei ein Problem.
Die einzige Moeglichkeit wie man UTF-8-Zeichen lesen kann ist byteweise.
Code: Alles auswählen
- an Position "0" im string gilt: Zahl < Nicht-Zahl
für den Fall "string is dotfile" gilt obige Regel für Position "1" im string
- an allen anderen Positionen im string gilt: Zahl > Nicht-Zahl
Und ist somit aktuell wieder in?
Code: Alles auswählen
len = mbstowcs(NULL, str, 0);
Gepflegt kurze Baerte sind wieder in, so Unix-Guru-Baerte, ich weiss nicht.
Hast du denn ein Testset? Also eine Liste von Strings, mit den erwarteten Erkennungs-/Vergleichsergebnissen, die du automatisch durchlaufen lassen kannst? Falls nicht, solltest du dir das unbedingt anlegen, weil deine Testerei sonst nicht nur aufwaendiger sondern auch lueckenhafter sein wird. Ausserdem ist so ein Testset zugleiche eine Dokumentation deiner Erwartungshaltung an das Programm.Doch bevor ich hier mal wieder eine neue Version einstelle um euch um eure Meinung zu bitten, will ich erst noch ein wenig mehr testen. Der Teufel versteckt sich ja bekanntlich im Detail...
Ja, aber das werde ich jetzt noch erweitern und zudem versuchen, das Ganze als "Unit-Test" professioneller zu gestalten. Dann kann die .c-Datei meiner compare-Funktion und ihrer Hilfsfunktionen in dem Projektordner meines file managers bleiben, bekommt aber eine eigene Makefile und ein extra Unit-Test-Programm mit einer header-Datei, welche die Test-Strings enthält. Dadurch, dass mein file-manager langsam hübsch modular wird, ist das ja nicht weiter schwierig.
Code: Alles auswählen
# rfm - Robert's file manager
# See LICENSE file for copyright and license details.
.POSIX:
INCS = -I. -I/usr/include
LIBS = -lncursesw
CPPFLAGS = -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700
CFLAGS = -ggdb -std=c99 -pedantic -Wall -Wextra -O0 $(INCS) $(CPPFLAGS)
LDFLAGS = $(LIBS)
CC = gcc
BIN = rfm
HDR = def.h config.h rfm.h
SRC = bind.c curses.c dir.c display.c filter.c info.c mycmp.c rfm.c wrappers.c
OBJ = ${SRC:.c=.o}
BIN_TEST = test/mycmp_test
HDR_TEST = test/mycmp_test.h
SRC_TEST = test/mycmp_test.c
OBJ_TEST = ${SRC_TEST:.c=.o}
all: $(BIN)
$(BIN): $(OBJ)
$(CC) $(CFLAGS) $(LDFLAGS) -o $(BIN) $^
$(OBJ): %.o: %.c $(HDR)
$(CC) $(CFLAGS) -c -o $@ $<
clean:
rm -f $(BIN) $(OBJ) $(BIN_TEST) $(OBJ_TEST)
test: $(BIN_TEST)
$(BIN_TEST): $(OBJ_TEST) mycmp.o
$(CC) $(CFLAGS) $(LDFLAGS) -o $(BIN_TEST) $^
$(OBJ_TEST): %.o: %.c $(HDR_TEST)
$(CC) $(CFLAGS) -c -o $@ $<
.PHONY: all clean test
?
Welche Regel greift eigentlich für "mycmp.o"? So wie ich es verstehe, müsste das die von "$(OBJ)" sein, richtig?RobertDebiannutzer hat geschrieben:24.04.2019 14:19:53Code: Alles auswählen
$(BIN_TEST): $(OBJ_TEST) mycmp.o
War das ein Wunsch nach Feedback auf den du keines bekommen hast und dich nun fragst warum nicht?
So Zeugs wie:Welche Regel greift eigentlich für "mycmp.o"? So wie ich es verstehe, müsste das die von "$(OBJ)" sein, richtig?RobertDebiannutzer hat geschrieben:24.04.2019 14:19:53Code: Alles auswählen
$(BIN_TEST): $(OBJ_TEST) mycmp.o
(Bei der Regel für "$(BIN_TEST)" habe ich noch die LDFLAGS entfernt, da ncurses da ja nicht gebraucht wird.)
Code: Alles auswählen
$(OBJ): %.o: %.c $(HDR)
Wenn Du so fragst, ja. ... Aber wie darf ich das jetzt verstehen?Meillo hat geschrieben:29.04.2019 10:43:06War das ein Wunsch nach Feedback auf den du keines bekommen hast und dich nun fragst warum nicht?
Code: Alles auswählen
$(OBJ): %.o: %.c $(HDR)
Code: Alles auswählen
# See LICENSE file for copyright and license details.
.POSIX:
INCS = -I. -I/usr/include
LIBS = -lncursesw
CPPFLAGS = -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700
CFLAGS = -ggdb -std=c99 -pedantic -Wall -Wextra -O0 $(INCS) $(CPPFLAGS)
LDFLAGS = $(LIBS)
CC = gcc
BIN = rfm
SRC = bind.c curses.c curses_readline.c dir.c display.c filter.c info.c mycmp.c rfm.c wrappers.c
OBJ = ${SRC:.c=.o}
BIN_TEST = test/mycmp_test
SRC_TEST = test/mycmp_test.c
OBJ_TEST = ${SRC_TEST:.c=.o}
%.o: %.c
$(CC) $(CFLAGS) -c -o $@ $<
all: $(BIN)
$(BIN): $(OBJ)
$(CC) $(CFLAGS) $(LDFLAGS) -o $(BIN) $^
clean:
rm -f $(BIN) $(OBJ) $(BIN_TEST) $(OBJ_TEST)
test: $(BIN_TEST)
$(BIN_TEST): $(OBJ_TEST) mycmp.o
$(CC) $(CFLAGS) -o $(BIN_TEST) $^
.PHONY: all clean test
Ich habe nur versucht dein Fragezeichen in Worte zu fassen. Vermutlich hat niemand auf deine Frage (``So?'') reagiert, weil niemandem etwas Offensichtliches aufgefallen ist und weil du schon geschrieben hast, dass es funktioniert und weil niemand sich die Muehe gemacht hat, genauer hinzuschauen.RobertDebiannutzer hat geschrieben:29.04.2019 11:29:54Wenn Du so fragst, ja. ... Aber wie darf ich das jetzt verstehen?Meillo hat geschrieben:29.04.2019 10:43:06War das ein Wunsch nach Feedback auf den du keines bekommen hast und dich nun fragst warum nicht?
Das ist auch recht so. Ich kann dir dabei halt nicht helfen. Aber dieses Forum bin ja nicht nur ich -- zum Glueck!Dies:ist eine "static pattern"-Regel: https://www.gnu.org/software/make/manua ... atic-UsageCode: Alles auswählen
$(OBJ): %.o: %.c $(HDR)
Damit kann ich unterschiedliche Rezepte aufstellen für $(OBJ) und $(OBJ__TEST). Das brauche ich zwar im Moment vielleicht nicht, aber ich mache das Ganze ja um was zu lernen und deswegen lote ich eben ein bisschen aus, was so möglich ist.
Was heisst ``funktionieren''? Aendere etwas in einer C-Datei und es funktioniert. Aendere nur etwas in einem Header und er wird gar nicht neu kompilieren wollen, weil noch alles up-to-date sei! (Vermute ich, ohne genauer hingeschaut zu haben.)Außerdem schien es mir nötig, für "$(OBJ)" und "$(OBJ_TEST)" unterschiedliche Regeln zu schaffen, da dafür ja unterschiedliche Header benötigt werden...
Aber vielleicht habe ich das mit der Header-Zuteilung noch nicht verstanden, denn es scheint gar keine Angabe von Headern notwendig zu sein.
Diese Makefile funktioniert nämlich auch:
[...]
Es ist durchaus nicht verkehrt, make die Header auch als Abhängigkeit bekannt zu machen. Sonst wird bei einer Änderung in einem Header, wie meillo schreibt, nicht neu gebaut.RobertDebiannutzer hat geschrieben:29.04.2019 11:29:54Aber vielleicht habe ich das mit der Header-Zuteilung noch nicht verstanden, denn es scheint gar keine Angabe von Headern notwendig zu sein.
Code: Alles auswählen
CFLAGS:=... -MMD ...
clean:
$(RM) ... *.d ...
-include $(wildcard *.d)
Code: Alles auswählen
CFLAGS:=... -MMD ...
DEPENDENCIES=$(OBJ:.o=.d) $(OBJ_TEST:.o=.d)
clean:
$(RM) ... $(DEPENDENCIES) ...
-include $(DEPENDENCIES)
Die Regel könntest du dir auch sparen, sie entspricht GNU makes eingebauter Regel für .o.RobertDebiannutzer hat geschrieben:29.04.2019 11:29:54Code: Alles auswählen
%.o: %.c $(CC) $(CFLAGS) -c -o $@ $<
Auch das entspricht der eingebauten Regel fürs Linken, es würde reichen, die Abhängigkeit anzugeben:RobertDebiannutzer hat geschrieben:29.04.2019 11:29:54Code: Alles auswählen
$(BIN): $(OBJ) $(CC) $(CFLAGS) $(LDFLAGS) -o $(BIN) $^
Code: Alles auswählen
$(BIN): $(OBJ)
Code: Alles auswählen
test: $(BIN_TEST)
./$(BIN_TEST)
Ach so ist das - danke!JTH hat geschrieben:29.04.2019 15:03:16Es ist durchaus nicht verkehrt, make die Header auch als Abhängigkeit bekannt zu machen. Sonst wird bei einer Änderung in einem Header, wie meillo schreibt, nicht neu gebaut.
Quelle: https://www.gnu.org/software/make/manua ... e-of-RulesThis manual only documents the default rules available on POSIX-based operating systems.
[...]
n.o is made automatically from n.c with a recipe of the form ‘$(CC) $(CPPFLAGS) $(CFLAGS) -c’.
[...]
n is made automatically from n.o by running the linker (usually called ld) via the C compiler. The precise recipe used is ‘$(CC) $(LDFLAGS) n.o $(LOADLIBES) $(LDLIBS)’. This rule does the right thing for a simple program with only one source file. It will also do the right thing if there are multiple object files (presumably coming from various other source files), one of which has a name matching that of the executable file. [...]
In more complicated cases, such as when there is no object file whose name derives from the executable file name, you must write an explicit recipe for linking.
Code: Alles auswählen
# rfm - Robert's file manager
# See LICENSE file for copyright and license details.
.POSIX:
INCS = -I. -I/usr/include
LIBS = -lncursesw
CPPFLAGS = -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700
CFLAGS = -ggdb -std=c99 -pedantic -Wall -Wextra -O0 $(INCS)
LDFLAGS = $(LIBS)
CC = gcc
BIN = rfm
HDR = config.h def.h rfm.h
SRC = bind.c curses.c curses_readline.c dir.c display.c filter.c info.c mycmp.c rfm.c wrappers.c
OBJ = ${SRC:.c=.o}
BIN_TEST = test/mycmp_test
HDR_TEST = test/mycmp_test.h
SRC_TEST = test/mycmp_test.c
OBJ_TEST = ${SRC_TEST:.c=.o}
all: $(BIN)
$(BIN): $(OBJ)
$(CC) $(CFLAGS) $(LDFLAGS) -o $(BIN) $^
$(OBJ): $(HDR)
clean:
rm -f $(BIN) $(OBJ) $(BIN_TEST) $(OBJ_TEST)
test: $(BIN_TEST)
@echo Starting unit test for mycmp.c ...
./$(BIN_TEST)
$(BIN_TEST): $(OBJ_TEST) mycmp.o
$(CC) $(CFLAGS) -o $(BIN_TEST) $^
$(OBJ_TEST): $(HDR_TEST)
.PHONY: all clean test
Alles klar, kein Problem.Meillo hat geschrieben:29.04.2019 11:39:07Vermutlich hat niemand auf deine Frage (``So?'') reagiert, weil niemandem etwas Offensichtliches aufgefallen ist und weil du schon geschrieben hast, dass es funktioniert und weil niemand sich die Muehe gemacht hat, genauer hinzuschauen.
Das ist ein sinnvolles Ziel. Da kommt man aber gerade bei Makefiles/Buildsystemen schnell an Grenzen und muss Compiler unterschiedlich behandeln oder greift irgendwann zu Autotools, CMake oder anderen Makefile-Generatoren (hier natürlich noch nicht notwendig ). Solange du laut Titel anscheinend eher noch am Lernen bist, würd ich mir mit Kompatibilität zu allen nur möglichen Compilern nicht bis ins letzte Detail Arbeit machen. Wo es sich mal am Rande anbietet, kann mans natürlich beachten.RobertDebiannutzer hat geschrieben:29.04.2019 22:45:26Die automatische Abhängigkeitslisten für die Header sind natürlich elegant, aber ich würde gerne auch kompatibel zu anderen Compilern sein - aber dennoch vielen Dank!
sowieso längst nicht mehr kompatibel.RobertDebiannutzer hat geschrieben:29.04.2019 22:45:26Code: Alles auswählen
CFLAGS = -ggdb -std=c99 -pedantic -Wall -Wextra -O0 $(INCS)
Das ist auch sinnvoll, möglichst wenige Flags können bei großem Projekt mit Glück die Buildzeiten kürzer halten.RobertDebiannutzer hat geschrieben:29.04.2019 22:45:26Ich habe allerdings fürs Linking die expliziten Regeln gelassen, damit mycmp_test nicht die ncurses-library abbekommt (sowas stört mich irgendwie, obwohl es ja nix macht).
Code: Alles auswählen
$(BIN): LDFLAGS+=-lncursesw
$(BIN): $(OBJ)
$(BIN_TEST): $(OBJ_TEST) mycmp.o
Nee, höchstens an tcc, weil der beim suckless-Projekt erwähnt wird (https://suckless.org/rocks/).
Stimmt ja. Dann werde ich das jetzt mal so machen mit den automatischen Abhängigkeitslisten.JTH hat geschrieben:30.04.2019 00:05:15Mit Compilern, die GCC-ähnliche Optionen nicht unterstützen, bist du mit den anderen benutzten CFLAGS
[...]
sowieso längst nicht mehr kompatibel.
Das ist toll, danke!JTH hat geschrieben:30.04.2019 00:05:15Vielleicht findest du den umgekehrten Weg noch eleganter, LDFLAGS nur für das eine Target zuzuweisen?
Quelle: https://www.gnu.org/software/make/manua ... l#FeaturesThe following features were inspired by various other versions of make. In some cases it is unclear exactly which versions inspired which others.
[...]
The ‘+=’ syntax to append to the value of a variable comes from SunOS 4 make.
Code: Alles auswählen
# rfm - Robert's file manager
# See LICENSE file for copyright and license details.
.POSIX:
INCS = -I. -I/usr/include
CPPFLAGS = -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700
CFLAGS = -ggdb -std=c99 -pedantic -Wall -Wextra -O0 -MMD $(INCS)
CC = gcc
BIN = rfm
SRC = bind.c curses.c curses_readline.c dir.c display.c filter.c info.c \
mycmp.c rfm.c wrappers.c
OBJ = $(SRC:.c=.o)
BIN_TEST = test/mycmp_test
SRC_TEST = test/mycmp_test.c
OBJ_TEST = $(SRC_TEST:.c=.o)
DEPENDENCIES = $(OBJ:.o=.d) $(OBJ_TEST:.o=.d)
-include $(DEPENDENCIES)
all: $(BIN)
$(BIN): LDFLAGS = -lncursesw
$(BIN): $(OBJ)
clean:
rm -f $(BIN) $(OBJ) $(BIN_TEST) $(OBJ_TEST) $(DEPENDENCIES)
test: $(BIN_TEST)
@echo Starting unit test for mycmp.c ...
./$(BIN_TEST)
$(BIN_TEST): $(OBJ_TEST) mycmp.o
.PHONY: all clean test
Code: Alles auswählen
(dev)user@hostname:~/dev/rfm$ make clean
rm -f rfm bind.o curses.o curses_readline.o dir.o display.o filter.o info.o mycmp.o rfm.o wrappers.o test/mycmp_test test/mycmp_test.o bind.d curses.d curses_readline.d dir.d display.d filter.d info.d mycmp.d rfm.d wrappers.d test/mycmp_test.d
(dev)user@hostname:~/dev/rfm$ make
gcc -ggdb -std=c99 -pedantic -Wall -Wextra -O0 -MMD -I. -I/usr/include -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 -c -o rfm.o rfm.c
gcc -ggdb -std=c99 -pedantic -Wall -Wextra -O0 -MMD -I. -I/usr/include -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 -c -o bind.o bind.c
gcc -ggdb -std=c99 -pedantic -Wall -Wextra -O0 -MMD -I. -I/usr/include -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 -c -o curses.o curses.c
gcc -ggdb -std=c99 -pedantic -Wall -Wextra -O0 -MMD -I. -I/usr/include -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 -c -o curses_readline.o curses_readline.c
gcc -ggdb -std=c99 -pedantic -Wall -Wextra -O0 -MMD -I. -I/usr/include -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 -c -o dir.o dir.c
gcc -ggdb -std=c99 -pedantic -Wall -Wextra -O0 -MMD -I. -I/usr/include -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 -c -o display.o display.c
gcc -ggdb -std=c99 -pedantic -Wall -Wextra -O0 -MMD -I. -I/usr/include -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 -c -o filter.o filter.c
gcc -ggdb -std=c99 -pedantic -Wall -Wextra -O0 -MMD -I. -I/usr/include -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 -c -o info.o info.c
gcc -ggdb -std=c99 -pedantic -Wall -Wextra -O0 -MMD -I. -I/usr/include -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 -c -o mycmp.o mycmp.c
gcc -ggdb -std=c99 -pedantic -Wall -Wextra -O0 -MMD -I. -I/usr/include -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 -c -o wrappers.o wrappers.c
gcc -lncursesw rfm.o bind.o curses.o curses_readline.o dir.o display.o filter.o info.o mycmp.o wrappers.o -o rfm
(dev)user@hostname:~/dev/rfm$ make clean
rm -f rfm bind.o curses.o curses_readline.o dir.o display.o filter.o info.o mycmp.o rfm.o wrappers.o test/mycmp_test test/mycmp_test.o bind.d curses.d curses_readline.d dir.d display.d filter.d info.d mycmp.d rfm.d wrappers.d test/mycmp_test.d
(dev)user@hostname:~/dev/rfm$ make test
gcc -ggdb -std=c99 -pedantic -Wall -Wextra -O0 -MMD -I. -I/usr/include -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 -c -o test/mycmp_test.o test/mycmp_test.c
gcc -ggdb -std=c99 -pedantic -Wall -Wextra -O0 -MMD -I. -I/usr/include -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 -c -o mycmp.o mycmp.c
gcc test/mycmp_test.o mycmp.o -o test/mycmp_test
Starting unit test for mycmp.c ...
./test/mycmp_test
There were 0 errors.
(dev)user@hostname:~/dev/rfm$ make clean
rm -f rfm bind.o curses.o curses_readline.o dir.o display.o filter.o info.o mycmp.o rfm.o wrappers.o test/mycmp_test test/mycmp_test.o bind.d curses.d curses_readline.d dir.d display.d filter.d info.d mycmp.d rfm.d wrappers.d test/mycmp_test.d
Der kann -MD (statt -MMD) und -g (statt -ggdb; -g eigentlich immer ausreichend). Aber bei -pedantic und -Wextra hörts dann aufRobertDebiannutzer hat geschrieben:30.04.2019 16:55:38Nee, höchstens an tcc, weil der beim suckless-Projekt erwähnt wird (https://suckless.org/rocks/).
Code: Alles auswählen
make: 'bind.o' is up to date.
Code: Alles auswählen
gcc -g -std=c99 -Wpedantic -Wall -Wextra -O0 -MMD -I. -I/usr/include -D_POSIX_C_SOURCE=200809L -D_XOPEN_SOURCE=700 -c -o curses_readline.o curses_readline.c
gcc -lncursesw rfm.o bind.o curses.o curses_readline.o dir.o display.o filter.o info.o mycmp.o wrappers.o -o rfm
Danke, dann lasse ich das erstmal, denn "-pedantic" und "-Wextra" erscheinen mir wichtig. BTW: Dank Deinem Tipp mit "-g" habe ich mir nochmal die Optionen von gcc genauer angeschaut und dabei zufällig auch gesehen, dass man neuerdings lieber "-Wpedantic" nutzen sollte statt nur "pedantic"...JTH hat geschrieben:30.04.2019 19:04:28Der kann -MD (statt -MMD) und -g (statt -ggdb; -g eigentlich immer ausreichend). Aber bei -pedantic und -Wextra hörts dann auf
Code: Alles auswählen
$ cat foo.d
foo.o: foo.c foo.h bar.h baz.h
Code: Alles auswählen
$ make
Code: Alles auswählen
bind.o: bind.c usw.
Oh. Bei der Kommandozeilen-Hilfe von gcc stand:JTH hat geschrieben:30.04.2019 22:07:44Hast du eine Begründung dafür gefunden, -Wpedantic dem -pedantic vorzuziehen? Ich dachte bisher, beide seien identisch, -Wpedantic aber erst bei neueren GCCs neu dazugekommen. Und -pedantic gibts eher auch bei anderen Compilern, von wegen der Kompatibilität
Code: Alles auswählen
--pedantic Same as -Wpedantic. Use the latter option instead.
-Wlong-long Do not warn about using "long long" when -pedantic.
-Wpedantic Issue warnings needed for strict compliance to the standard.
-pedantic Same as -Wpedantic. Use the latter option instead.
--pedantic-errors Same as -pedantic-errors. Use the latter option instead.
Quelle: https://gcc.gnu.org/gcc-4.8/changes.htmlThe new option -Wpedantic is an alias for -pedantic, which is now deprecated.