C als Ausbildungssprache
Tobias Bell
habt ihr schon mal eine Ausbildung im IT-Bereich genossen und dabei
die Sprache C lernen dürfen? Ja, und habt ihr euch darüber geärgert,
dass man euch Fehler anstreicht, die keine sind? Dann jetzt die
ultimativen Tips um dies zu umgehen.
1) Schreibt in den Kommentar bei der Angabe der Sprache nicht etwa
`ISO C90', das ist falsch. Man schreibt einfach C hin. Es gibt ja nur
_ein_ C. (Niemand kennt ISO C99)
2) Ihr solltet den verwendeten Compiler in jedes .c und h-File
schreiben. Aber schreibt nicht etwa wirklich den Compiler den ihr
verwendet. Schreibt besonders nicht `gcc'. Sowas kennt niemand, muss
völlig unbekannt sein. Schreibt rein `Microsoft Visual Studio 6.0'.
Computer => Microsoft, Compiler => Visual Studio
3) Codeformatierung nach Kernigham-Ritchie ist unüblich
if(foo) {
...
...
} else {
...
...
}
Das macht doch niemand. Das muss man so machen
if(foo)
{
}
else
{
}
4) malloc muss gecastet werden
int *p = (int*)malloc(5*sizeof(int))
5) immer sizeof nehmen, denn `char' könnte ja was anderes als 1 sein
char c = (char*) malloc(5*sizeof(char))
6) sizeof ist auch kein Operator, da müssen Klammern drum
7) Schreibt bloß kein portables C, benutzt
#include <conio.h>
8) Ganz wichtig
#include <stdlib.h>
int main(void)
{
...
...
return EXIT_SUCCESS;
}
ist nicht beliebt. Das heißt
void main()
{
}
9) Fehlermeldungen auf `stderr' ausgeben ist unüblich. Nehmt immer
`stdout'
10) Es gibt nur printf. printf("%s", "blabla") ist besser als
puts("blabla");
Ich könnte kotzen.
Gruß Tobias
Claus Reibenstein
> Hallo,
>
> habt ihr schon mal eine Ausbildung im IT-Bereich genossen und dabei
> die Sprache C lernen dürfen? Ja, und habt ihr euch darüber geärgert,
> dass man euch Fehler anstreicht, die keine sind? Dann jetzt die
> ultimativen Tips um dies zu umgehen.
>
> [viele Gründe, um sein Geld zurück zu verlangen]
Wie heißt denn das "tolle" Institut, bei dem Du diese "Tipps" gelernt
hast? Sollte man öffentlich brandmarken.
Gruß. Claus
Ralf Bartzke
> 3) Codeformatierung nach Kernigham-Ritchie ist unüblich
>
> if(foo) {
> ...
> ...
> } else {
> ...
> ...
> }
>
> Das macht doch niemand. Das muss man so machen
>
> if(foo)
> {
>
> }
> else
> {
>
> }
>
> 4) malloc muss gecastet werden
>
> int *p = (int*)malloc(5*sizeof(int))
Schadet wenigstens nichts.
>
> 5) immer sizeof nehmen, denn `char' könnte ja was anderes als 1 sein
>
> char c = (char*) malloc(5*sizeof(char))
Korrekt.
> 8) Ganz wichtig
>
> #include <stdlib.h>
> int main(void)
> {
> ...
> ...
> return EXIT_SUCCESS;
> }
>
> ist nicht beliebt. Das heißt
>
> void main()
> {
>
>
> }
Er kommt halt aus der Windows-Welt. Wozu einen Fehlercode ohne
Fehlermöglichkeit.
>
> 9) Fehlermeldungen auf `stderr' ausgeben ist unüblich. Nehmt immer
> `stdout'
Hat Vor- und Nachteile. Hab gelesen, stderr sei aufwendiger, weil es
auch bei zerschossenem Stack noch funktionieren soll.
>
> 10) Es gibt nur printf. printf("%s", "blabla") ist besser als
> puts("blabla");
Blödsinn.
> Ich könnte kotzen.
Du bist möglicherweise auf einen der Normalfälle unseres Bildungssystems
gestossen. Das kann sehr gefährlich werden, für den Betroffenen.
>
> Gruß Tobias
Mein Beileid. Am besten stellst Du dich ganz dumm und lernwillig.
Probleme, von denen keiner was merkt, sind unwichtig.
Ralf
Carsten Krueger
>4) malloc muss gecastet werden
>
>int *p = (int*)malloc(5*sizeof(int))
Warum denn auch nicht?
>10) Es gibt nur printf. printf("%s", "blabla") ist besser als
>puts("blabla");
gets will man nicht benutzen, also währe es konsequent auch puts nicht
zu benuzen.
Gruß Carsten
--
http://learn.to/quote - richtig zitieren
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://oe-faq.de/ - http://www.oe-tools.de.vu/ - OE im Usenet
http://www.spamgourmet.com/ - Emailadresse(n) gegen Spam
Claus Reibenstein
> Tobias Bell schrieb:
>
> Dein Ausbilder braucht ne Ausbildung.
Das ist definitiv richtig.
>>4) malloc muss gecastet werden
>>
>>int *p = (int*)malloc(5*sizeof(int))
>
> Schadet wenigstens nichts.
Es sei denn, man vergisst, die <stdlib.h> zu #includen (ich liebe diese
"Sprache"). Und nach dem, was ich hier gelesen habe, gehe ich mal davon
aus, dass dem Ausbilder genau das passiert ist, weshalb er eine
Fehlermeldung bekommen und diesen Fehler durch den Cast "korrigiert" hat.
>>5) immer sizeof nehmen, denn `char' könnte ja was anderes als 1 sein
>>
>>char c = (char*) malloc(5*sizeof(char))
>
> Korrekt.
Du brauchst auch eine Ausbildung ...
Gruß. Claus
Claus Reibenstein
> tobia...@web.de (Tobias Bell) wrote:
>
>>4) malloc muss gecastet werden
>>
>>int *p = (int*)malloc(5*sizeof(int))
>
> Warum denn auch nicht?
Weil es mögliche Fehler verdeckt.
>>10) Es gibt nur printf. printf("%s", "blabla") ist besser als
>>puts("blabla");
>
> gets will man nicht benutzen, also währe es konsequent auch puts nicht
> zu benuzen.
scanf will man auch nicht benutzen, also sollte man konsequenterweise
auch auf printf verzichten ;-)
Gruß. Claus
Stephan Aspridis
> Hallo,
>
> habt ihr schon mal eine Ausbildung im IT-Bereich genossen und dabei
> die Sprache C lernen dürfen? Ja, und habt ihr euch darüber geärgert,
> dass man euch Fehler anstreicht, die keine sind? Dann jetzt die
> ultimativen Tips um dies zu umgehen.
>
11) Hau dem Vollpfosten von Dozent den Kernighan-Ritchie so lange um die
Ohren, bis er es rafft.
Gruß,
Stephan
Rainer Weikusat
>> 4) malloc muss gecastet werden
>> int *p = (int*)malloc(5*sizeof(int))
> Schadet wenigstens nichts.
Doch. Ein C89-kompatibler Compiler wird implicit int annehmen, wenn er
keinen Prototyp bekommt, und das ist für einen Zeiger möglicherweise
nicht groß genug.
>> 5) immer sizeof nehmen, denn `char' könnte ja was anderes als 1 sein
>> char c = (char*) malloc(5*sizeof(char))
> Korrekt.
Nein. sizeof(char) == 1 ist so festgelegt.
>> 8) Ganz wichtig
>> #include <stdlib.h>
>> int main(void)
>> {
>> ...
>> ...
>> return EXIT_SUCCESS;
>> }
>> ist nicht beliebt. Das heißt
>> void main()
>> {
>> }
> Er kommt halt aus der Windows-Welt. Wozu einen Fehlercode ohne
> Fehlermöglichkeit.
Die Shell schon gefunden?
>> 9) Fehlermeldungen auf `stderr' ausgeben ist unüblich. Nehmt immer
>> `stdout'
> Hat Vor- und Nachteile.
Vorteil hat es keinen und es hat den Nachteil, daß die
Programmausgabe geparst werden muß, bevor man sie weiterverarbeiten
kann.
> Hab gelesen, stderr sei aufwendiger, weil es
> auch bei zerschossenem Stack noch funktionieren soll.
stderr ist ungepuffert, dh jede Ausgabe erfolgt vor der Rückkehr der
Ausgabefunktion ins Programm und nicht erst blockweise 'irgendwann
später'. Rationale: Es ist dringend, sonst wäre es kein Problem.
Stefan Reuther
Tobias Bell <tobia...@web.de> wrote:
> 1) Schreibt in den Kommentar bei der Angabe der Sprache nicht etwa
> `ISO C90', das ist falsch. Man schreibt einfach C hin. Es gibt ja nur
> _ein_ C. (Niemand kennt ISO C99)
Mit 'ANSI C' hättest du vielleicht mehr Glück. Der Begriff kommt
immerhin sogar in der MSVC-Hilfe vor.
Dabei aber nicht vergessen, daß *natürlich* ANSI-C //-Kommentare
unterstützt.
> 3) Codeformatierung nach Kernigham-Ritchie ist unüblich
[...]
> Das macht doch niemand. Das muss man so machen
> if(foo)
> {
> }
Du hast das wichtigste vergessen: im Editor Tab-Size = 4
einstellen, damit wirklich niemand auf die Idee kommt, den Kot
mit etwas anderem als MSVC anzusehen.
> 4) malloc muss gecastet werden
> int *p = (int*)malloc(5*sizeof(int))
Als Ersatz für das wegzulassende '#include <stdlib>' doch gar
nicht schlecht.
Aber ansonsten heißt das nicht 'malloc', sondern '_farmalloc'.
> 6) sizeof ist auch kein Operator, da müssen Klammern drum
Das ist ausnahmsweise mal nicht verkehrt. 'sizeof(int)'.
> 9) Fehlermeldungen auf `stderr' ausgeben ist unüblich. Nehmt immer
> `stdout'
Na logisch - wie soll man die denn sonst die Fehlermeldungen
nach \dev\nul umleiten? Für das offensichtliche Ziel-
Betrübssystem ist nun mal die etablierte Verfahrensweise für
Fehlermeldungen 'wegwerfen' bzw. 'wegklicken'.
Aber du hast die wichtigen Sachen vergessen:
11) 'int' ist immer 16 Bit
12) am Ende eines jeden Programmes die Funktion 'getch()'
aufrufen. Sonst geht ja das DOS-Fenster immer so schnell zu.
13) seit wann hat 'scanf' einen Rückgabewert?
14) nur Weicheier prüfen den Rückgabewert von 'malloc'
15) 'c |= 0x20' ist schneller als 'c = tolower(c)' und macht das
gleiche.
16) Warnungen ignoriert man. Dafür bekommt man Riesen-Panik,
wenn im Ausgabefenster steht
Process ÜBUNG.EXE terminated with code 0x20C02354
(ungefähr so erzählt dir MSVC, daß du mal wieder das 'return 0'
in main vergessen hast).
17) Debugger sind langweilig. Es ist viel spannender, dem
Übungsleiter eine wüste Sonderzeichensammlung vorzulegen und zu
sagen 'geht nicht'. Der findet den Fehler schon. Die gezeigten
Menüpunkte (Kontextmenü -> Set breakpoint) muß man sich nicht
merken. Das ist geheimes Übungsleiter-Spezialwissen.
18) wer einmal ein C-Praktikum gemacht hat, hat damit das Recht
auf lebenslangen Support beim Übungsleiter erworben. Der
Übungsleiter hilft gerne auch beim Schreiben von OpenGL-,
Windows- und Assembler-Programmen.
19) Übungsleiter lesen liebend gerne Manualseiten vor. Selbst
wenn der Übungsleiter den entsprechenden Absatz im Handbuch
markiert, muß man nicht selbst lesen - falls der erste Halbsatz
das Problem nicht löst, nervt man einfach weiter.
> Ich könnte kotzen.
Du könntest den nächsten Kurs übernehmen. Das habe ich getan,
als mir die C-Übungen zu bunt wurden. Um zu der Erkenntnis zu
gelangen: mit viel Energie kann man tatsächlich Leuten
Grundlagen der Programmierung in C beibringen. Es gibt sogar
Leute, die mitarbeiten, lernen und tatsächlich gute Programme
zustande bringen (mein Favorit bisher war eine Gruppe, die alle
Sortieralgorithmen aus dem Theorie-Script implementiert und
gegeneinander antreten lassen hat :-) Ob der Prozentsatz solcher
Leute höher oder niedriger als bei Java/Pascal/Perl/Haskell/...
ist, mag ich nicht beurteilen.
Es bringt aber auch die Erkenntnis: als Hiwi kannst du am
Lehrplan nicht viel ändern, hast aber nachher Problem 17 bis 19
am Hals :-(
Der Lichtblick: es gibt auch *wirklich gute* Leute. Die kommen
aber nicht in so einen Kurs. Ich kenn hier jemanden, der seit
ca. 6 Monaten mit einem Buch 'C-Programmierung unter Linux'
(oder so) lernt. Selbstgestecktes Ziel: ein OpenGL-Spiel (ja, er
weiß, daß OpenGL != C ist). Das gute daran: es funktioniert, es
sieht gut aus (sowohl das Spiel, als auch der Code), und ist
sehr fehlerarm.
Stefan
Ralf Bartzke
>>>
>>>char c = (char*) malloc(5*sizeof(char))
>>
>>Korrekt.
>
> Du brauchst auch eine Ausbildung ...
>
> Gruß. Claus
>
char *pc = (char*) malloc(5*sizeof(char));
Ralf
Tobias Bell
> Tobias Bell schrieb:
Es geht um eine Ausbildung zum mathematisch-technischen Assistenten,
von der ich im allgemeinen sehr überzeugt bin. Wir machen Mathematik
auf höherem Niveau, wir lernen Algorihmen sprachunahängig und die
Trainer sind im allgemeinen auch kompetent. Allerdings ist ihre
Sprachkenntnis nicht immer hervorragend. Das Problem sind nur die
Korrektoren dieser Sprachklausuren. Da wird einem an die Prüfung
geschrieben, man wolle extra tricky und kompliziert programmieren,
weil man nicht nur printf nutzt, stderr benötigt, malloc nicht castet
und Sachen wie
int *p = malloc(15*sizeof(*p));
if(!p) {
....
....
} else {
....
}
schreibt. Alleine schon der Code-Style sei ja eine Zumutung. Zur
prüfung werde ich wohl teilweise "merkwürdigen" Code schreiben, um
eine bessere Note zu erhalten.
Gruß Tobias
--
I'm just a stupid white man like them all.
Alexander Bartolich
> [...] stderr ist ungepuffert, dh jede Ausgabe erfolgt vor der
> Rückkehr der Ausgabefunktion ins Programm und nicht erst
> blockweise 'irgendwann später'.
man setvbuf
# _IONBF unbuffered
# _IOLBF line buffered
# _IOFBF fully buffered
AFAIK ist stderr "line buffered", nicht "unbuffered".
--
Mögen die Schwingen des Koffeins in lichte Höhen tragen.
Harald Wenninger
> AFAIK ist stderr "line buffered", nicht "unbuffered".
Nope.
man stderr
[...]
The stream stderr is unbuffered. The stream stdout is line-buffered when
it points to a terminal.
[...]
Gruß,
Harald
Rainer Weikusat
> begin Rainer Weikusat:
>> [...] stderr ist ungepuffert, dh jede Ausgabe erfolgt vor der
>> Rückkehr der Ausgabefunktion ins Programm und nicht erst
>> blockweise 'irgendwann später'.
[...]
> AFAIK ist stderr "line buffered", nicht "unbuffered".
Genaugenommen ist er 'not fully buffered' aber sinnvollerweise sollte
er überhaupt nichts zwischenspeichern. Das ergibt sich aus dem Sinn
von diagnostics, nämlich in Abhängigkeit bestimmter wichtiger
Ereignisse Ausgaben zu einem bestimmten Zeitpunkt zu machen.
Rainer Weikusat
> Da wird einem an die Prüfung geschrieben, man wolle extra tricky und
> kompliziert programmieren, weil man nicht nur printf nutzt, stderr
> benötigt, malloc nicht castet und Sachen wie
>
> int *p = malloc(15*sizeof(*p));
>
> if(!p) {
> ....
> ....
> } else {
> ....
> }
>
> schreibt. Alleine schon der Code-Style sei ja eine Zumutung.
Ja. Und? Dem entnehmen wir, daß der Mensch, der da korrigiert, keine
bis wenig praktische Erfahrungen mit Code, der von unterschiedlichen
Personen geschrieben wurde, hat (oberste Regel: Egal wie, aber bitte
konsistent) und keine Lust, Dinge die er/sie nicht auswendig weiß,
irgendwo nachzuschlagen. Gegen Geblubber als Begründung einer Note
kann man Rechtsmittel einlegen. Funktionsfähigkeit einer Problemlösung
ist verifizierbar. Wo ist das Problem?
Jirka Klaue
> Tobias Bell <tobia...@web.de> wrote:
...
>>6) sizeof ist auch kein Operator, da müssen Klammern drum
>
> Das ist ausnahmsweise mal nicht verkehrt. 'sizeof(int)'.
Aber sizeof ist doch ein Operator. Und es müssen nur Klammern
drum, wenn es auf einen Typ angewendet wird.
Jirka
Harald Wenninger
[...]
> Gegen Geblubber als Begründung einer Note
> kann man Rechtsmittel einlegen. Funktionsfähigkeit einer Problemlösung
> ist verifizierbar. Wo ist das Problem?
Man will sich damit nicht lange rumärgern müssen?
Gruß,
Harald
Ralf Bartzke
> Ralf Bartzke <ralf.b...@t-online.de> writes:
>
> Nein. sizeof(char) == 1 ist so festgelegt.
Ist das so? Ich habe folgendes gelesen:
"In C++ ist sizeof(char) = 1"
> stderr ist ungepuffert, dh jede Ausgabe erfolgt vor der Rückkehr der
> Ausgabefunktion ins Programm und nicht erst blockweise 'irgendwann
> später'. Rationale: Es ist dringend, sonst wäre es kein Problem.
Ich habe schon gesehen, dass dadurch die zeitliche Abfolge von
Statusmeldungen eines Programms und Fehlermeldungen vollkommen
durcheinanderkommt.
Ralf
Jirka Klaue
> Rainer Weikusat schrieb:
>> Ralf Bartzke <ralf.b...@t-online.de> writes:
>>
>> Nein. sizeof(char) == 1 ist so festgelegt.
>
> Ist das so? Ich habe folgendes gelesen:
>
> "In C++ ist sizeof(char) = 1"
Das stimmt auch.
Und jetzt lies noch: "In C ist sizeof(char) == 1".
Jirka
Stefan Reuther
>>
>> Ist das so? Ich habe folgendes gelesen:
>>
>> "In C++ ist sizeof(char) = 1"
> Das stimmt auch.
> Und jetzt lies noch: "In C ist sizeof(char) == 1".
Und ich werfe
C++: sizeof 'a' == 1
C: sizeof 'a' == sizeof(int)
in die Runde.
Stefan
Stefan Reuther
Ja, aber Klammern bei einem Ausdruck schaden nicht und verdecken
im Gegensatz zu dem malloc-cast auch keine Fehler.
Stefan
Alexander Busch
> Rainer Weikusat schrieb:
> > Ausgabefunktion ins Programm und nicht erst blockweise 'irgendwann
> > später'. Rationale: Es ist dringend, sonst wäre es kein Problem.
> Ich habe schon gesehen, dass dadurch die zeitliche Abfolge von
> Statusmeldungen eines Programms und Fehlermeldungen vollkommen
> durcheinanderkommt.
Ja und? Dafür sind es nun einmal Fehlermeldungen, die durchaus die
Statusmeldungen "durcheinanderbringen" (sprich sich dazwischen
schieben) dürfen.
Ich möchte halt möglichst früh wissen, wenn ein Programm gedenkt den
dritten Weltkrieg auszulösen. ;)
Falls man Fehlermeldungen nicht sehen möchte, wenn der Fehler
auftritt, kann man ja stderr immer noch umleiten.
(Wobei aber auch einige Programme mit ihren "Fehlermeldung" nicht
geizen... z.B. "Low CPU detected, switching to emulation..." sehe ich
nicht wirklich als Fehler der nach stderr gehört.)
Gruß,
Alexander
Rainer Weikusat
> Jirka Klaue <jkl...@ee.tu-berlin.de> wrote:
>> Das stimmt auch.
>> Und jetzt lies noch: "In C ist sizeof(char) == 1".
>
> Und ich werfe
> C++: sizeof 'a' == 1
> C: sizeof 'a' == sizeof(int)
> in die Runde.
Wie bereits verschiedentlich gepostet: 'a' ist in C eine
Integerkonstante mit einem seltsamen Namen.
Tobias Bell
> Ja. Und? Dem entnehmen wir, daß der Mensch, der da korrigiert, keine
> bis wenig praktische Erfahrungen mit Code, der von unterschiedlichen
> Personen geschrieben wurde, hat (oberste Regel: Egal wie, aber bitte
> konsistent) und keine Lust, Dinge die er/sie nicht auswendig weiß,
> irgendwo nachzuschlagen. Gegen Geblubber als Begründung einer Note
> kann man Rechtsmittel einlegen. Funktionsfähigkeit einer Problemlösung
> ist verifizierbar. Wo ist das Problem?
Es ist kein Problem, es ist nur ärgerlich und unangenehm einem
Korrektor zu sagen, dass er wenig Ahnung von der Sprache C hat und das
die Welt der IT nicht nur aus Microsoft und deren C++-Compiler besteht.
Zumal der direkte Kontkt zum Korektor auch nicht immer direkt gegeben
ist und einem nahegelegt wird zur IHK-Abschlussprüfung doch lieber den
Code-Style zu verändern, wo es doch überhaupt keine Vorgaben zur
Code-Formatierung außer der zu verwendenden Sprache (ISO C90) gibt.
Und die ist wie bekannt ja recht formatfrei.
Gruß Tobias Bell
Michael Stricker
> Hallo,
>
> habt ihr schon mal eine Ausbildung im IT-Bereich genossen und dabei
> die Sprache C lernen dürfen? Ja, und habt ihr euch darüber geärgert,
> dass man euch Fehler anstreicht, die keine sind? Dann jetzt die
> ultimativen Tips um dies zu umgehen.
Funktioniert vielleicht an der Uni, aber nicht auf Schulen mit IHK-Zulassung,
weil dort sitzen nur weltfremde Deppen, die sich unsinnige Prüfungen und
Programmieraufgaben ausdenken und Hinweise auf anderen Compiler und
Sprachvariaten gar nicht kennen bzw. solche Hinweise im Prüfungstext nicht
beachten und dann trotzdem eine schlechte Note verteilen (leider selbst erlebt).
Jirka Klaue
Stimmt. Nichtsdestotrotz sind beide Aussagen aus 6) falsch.
Jirka
Vinzent 'Gadget' Hoefler
>Ich möchte halt möglichst früh wissen, wenn ein Programm gedenkt den
>dritten Weltkrieg auszulösen. ;)
Du hast Hoffnung, in einem solchen Fall eine *Fehler*-Meldung zu
bekommen? Optimist.
>(Wobei aber auch einige Programme mit ihren "Fehlermeldung" nicht
>geizen... z.B. "Low CPU detected, switching to emulation..." sehe ich
>nicht wirklich als Fehler der nach stderr gehört.)
ACK. Das ist kein Fehler. Die zugehoerige Ausgabe gehoert nach
stddiag.
Vinzent.
Juergen Ilse
Tobias Bell <tobia...@web.de> wrote:
> habt ihr schon mal eine Ausbildung im IT-Bereich genossen und dabei
> die Sprache C lernen dürfen? Ja, und habt ihr euch darüber geärgert,
> dass man euch Fehler anstreicht, die keine sind? Dann jetzt die
> ultimativen Tips um dies zu umgehen.
Wenn ich deine Auflistung so lese, kommt in mir der Verdacht auf, dass
viele der "Fehler die keine sind", auf die du dich beziehst, wirkliche
Fehler sind ...
> 1) Schreibt in den Kommentar bei der Angabe der Sprache nicht etwa
> `ISO C90', das ist falsch. Man schreibt einfach C hin. Es gibt ja nur
> _ein_ C. (Niemand kennt ISO C99)
Das ist flacsh. Es gibt mehrere "C-Dialekte" die hier in der Gruppe
On-Topic sind: das historische K&R C (das allerdings zu recht kaum
noch Verwendung in aktuellen Entwicklungen findet und manche Sachen
auch nicht unbedingt genau spezifiziert hat), dann C89/C90 und schliess-
lich der aktuelle Standard C99.
> 2) Ihr solltet den verwendeten Compiler in jedes .c und h-File
> schreiben. Aber schreibt nicht etwa wirklich den Compiler den ihr
> verwendet. Schreibt besonders nicht `gcc'. Sowas kennt niemand, muss
> völlig unbekannt sein. Schreibt rein `Microsoft Visual Studio 6.0'.
> Computer => Microsoft, Compiler => Visual Studio
Der "Tip" ist IMHO absolut hirnrissig.
> 3) Codeformatierung nach Kernigham-Ritchie ist unüblich
> if(foo) {
> ...
> ...
> } else {
> ...
> ...
> }
Nein, ist sie nicht. Allerdings sollte man sich bei Projekten, an denen
mehrere Leute arbeiten auf einen einheitlichen Stil einigen.
> Das macht doch niemand. Das muss man so machen
> if(foo)
> {
> }
> else
> {
> }
Das ist eine Sache der verwendeten "Coding-Richtlinien" und *kann* so
aussehen, muss aber nicht.
> 4) malloc muss gecastet werden
> int *p = (int*)malloc(5*sizeof(int))
In C++ waere der cast notwendig, in C verdeckt er manchmal Fehler bzw.
Warnungen (z.B. fehlende includes und damit verbunden einen fehlenden
Prototyp fuer malloc). Wenn man nicht auf C++-Kompatibilitaet angewiesen
ist (und auch in Zukunft nicht angewiesen sein wird) sollte man IMHO
den cast weglassen.
> 5) immer sizeof nehmen, denn `char' könnte ja was anderes als 1 sein
> char c = (char*) malloc(5*sizeof(char))
Schwachsinn! Der sizeof-Operator liefert per Definition die Groesse
in "char", also ist sizeof(char) per Definition *immer* 1. Du darfst
das auch gerne im C-Standard nachlesen, wenn du es nicht glaubst.
Allerdings ist die Groesse eines "char" vom Standard nciht festgelegt
(es gibt Plattformen, auf denen sizeof(char)==sizeof(int)==1).
> 6) sizeof ist auch kein Operator, da müssen Klammern drum
sizeof ist ein Operator (nachzulesen im Standard).
> 7) Schreibt bloß kein portables C, benutzt
> #include <conio.h>
Schwachsinn!
> 8) Ganz wichtig
> #include <stdlib.h>
> int main(void)
> {
> ...
> ...
> return EXIT_SUCCESS;
> }
> ist nicht beliebt. Das heißt
Schwachsinn.
> void main()
> {
> }
... ist unportabel und funktioniert u.U. eher nur zufaellig. Der Vax-C
Compiler unter aelteren VMS-Versionen hat so etwas zwar geschluckt,
aber bei der Ausfuehrung des Programms kam am Ende eine Fehlermeldung,
wenn der exit-status ungleich 0 war (und bis einschliesslich C89/C90
war er oft genug ungleich 0, wenn man nicht explizit eine 0 zurueckge-
geben oder exit(0) aufgerufen hat ...).
> 9) Fehlermeldungen auf `stderr' ausgeben ist unüblich. Nehmt immer
> `stdout'
Schwachsinn. Wer jemals mit unix-aehnlichen Systemen zu tun hatte,
weiss auch den Grund, warum stdout und stderr *unterschiedlich*
sind und welche Vorteile das hat.
> 10) Es gibt nur printf. printf("%s", "blabla") ist besser als
> puts("blabla");
Schwachsinn. Allerdings wuerde ich keine Regel vorgeben wollen, was
davon zu bevorzugen waere ...
> Ich könnte kotzen.
Wenn diese "Tips" vom Dozenten kamen (bzw. er die Einhaltung erwartet
hat), ist das verstaendlich. Ansonsten sollte man bei jedem *solchen*
Fehler, den der Dozent angestrichen hat, dazu uebergehen, ihm seinen
Irrtum anhand des C-Standards zu *belegen* und sich notfalls bei seinem
Vorgesetzten beschweren.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Das Netz ist Freude. Es ist Ekstase, die jeden einzelnen Nerv erglühen
läßt. Es ist Duft, den man fühlt. Es ist ein Bild, das man riecht.
Es ist Erfüllung - ein Geschmack, neben dem alles andere schal ist.
("Netzreiter-Preisung" aus dem Buch "Der Netzparasit" von Andreas Brandhorst)
Tobias Bell
> Tobias Bell schrieb:
Was für eine Ausbildung hast du denn genossen. Ich lege gerade die
Prüfung zum "Mathematisch-technischen Assistenten/Informatik
(IHK)"(TM) ab bzw. schreibe nächste Woche die Prüfungen. Gott sei
gelobt und gedankt, dass das keine berufsschulpflichtige Ausbildung
ist. Sonst hätte ich mich bestimmt schon selbst entleibt. Die Trainer
sind auch lernfähig und lassen sich sogar Nachhilfe in C geben. Sind
aber in algorithmischen Dingen recht fit. Wenn ich da immer das
Wehklagen der Fach-Infs höre ... Jetzt müßte ich nur noch die
IHK-Prüfer dazu bekehren sich mal den C-Standard näher zu betrachten.
Was solls zur Not schreibe ich halt Müll-Code. Ist ja keine Religion
hier.
Gruß Tobias Bell
Juergen Ilse
Tobias Bell <tobi...@expires-30-11-2003.news-group.org> wrote:
> Sprachkenntnis nicht immer hervorragend. Das Problem sind nur die
> Korrektoren dieser Sprachklausuren. Da wird einem an die Prüfung
> geschrieben, man wolle extra tricky und kompliziert programmieren,
> weil man nicht nur printf nutzt, stderr benötigt, malloc nicht castet
> und Sachen wie
> int *p = malloc(15*sizeof(*p));
> if(!p) {
Bei dieser Zeile haette ich vermutlich ein "if (p == NULL)"
geschrieben, aber ich weiss, dass das eher Geschmacksache ist ...
> ....
> ....
> } else {
> ....
> }
> schreibt. Alleine schon der Code-Style sei ja eine Zumutung. Zur
> prüfung werde ich wohl teilweise "merkwürdigen" Code schreiben, um
> eine bessere Note zu erhalten.
Man sollte sich vermutlich hartnaeckig ueber die Korrektoren
beschweren. Wenn die nicht in der Lage sind, solchen Code zu
korrigieren, sollte man sie nicht als Korrektoren fuer solche
Uebungen einsetzen. Wenn sich niemand beschwert, wird sich da
aber wohl eher nichts (oder nur wenig und langsam) aendern ...
Alexander Bartolich
> Bei dieser Zeile haette ich vermutlich ein "if (p == NULL)"
> geschrieben, aber ich weiss, dass das eher Geschmacksache ist ...
NULL considered harmful.
--
Für Google, Tux und GPL!
Juergen Ilse
Ralf Bartzke <ralf.b...@t-online.de> wrote:
> Tobias Bell schrieb:
>> void main()
>> {
>>
>>
>> }
> Er kommt halt aus der Windows-Welt. Wozu einen Fehlercode ohne
> Fehlermöglichkeit.
Weil der standard nicht garantiert, dass sich so etwas in einem "hosted
environment" ueberhaupt uebersetzen laesst und weil man gern portable
Programme schreiben moechte? Ausserdem kann man auch unter Windows durch-
aus den Status eines beendeten Programms abfragen (das ging auch schon
unter DOS und war dort trotz der etwas eingeschraenkten Moeglichkeiten
sinvoll:
if %errorlevel% = 1 goto fehler
Wenn der Korrektor den Sinn dari9n nicht erkennen kann, hat er offenbar
nicht nur ein Problem mit dem Verstaendnis der Sprache C ...).
>> Ich könnte kotzen.
> Du bist möglicherweise auf einen der Normalfälle unseres Bildungssystems
> gestossen. Das kann sehr gefährlich werden, für den Betroffenen.
> Mein Beileid. Am besten stellst Du dich ganz dumm und lernwillig.
> Probleme, von denen keiner was merkt, sind unwichtig.
... und damit zementiert man den beschissenen Status auch noch fuer
alle nachfolgenden ... Prima!
Juergen Ilse
Das heisst, das stderr auf dem System, auf dem das die Beschreibung
von stderr ist, ungepuffert ist. IIRC besagt das der Sprachstandard
aber nicht, also kann stderr auch "line-buffered" sein ohne den Standard
zu verletzen. aus 7.19.3 (unter Punkt 7):
------------------------------
As initially opened, the standard error stream is not fully buffered;
the standard input und standard output streams are fully buffered if
and only if the stream can be determined not to refer to an interactive
device.
------------------------------
Juergen Ilse
Stefan Reuther <sr...@inf.tu-dresden.de> wrote:
> Tobias Bell <tobia...@web.de> wrote:
>> 1) Schreibt in den Kommentar bei der Angabe der Sprache nicht etwa
>> `ISO C90', das ist falsch. Man schreibt einfach C hin. Es gibt ja nur
>> _ein_ C. (Niemand kennt ISO C99)
> Mit 'ANSI C' hättest du vielleicht mehr Glück. Der Begriff kommt
> immerhin sogar in der MSVC-Hilfe vor.
> Dabei aber nicht vergessen, daß *natürlich* ANSI-C //-Kommentare
> unterstützt.
Ist ja auch korrekt (fuer den aktuellen Standard), nur unterstuetzt VC++
leider nicht den (aktuellen) ANSI-Standard ...
;-)
>> Ich könnte kotzen.
> Du könntest den nächsten Kurs übernehmen. Das habe ich getan,
> als mir die C-Übungen zu bunt wurden. Um zu der Erkenntnis zu
> gelangen: mit viel Energie kann man tatsächlich Leuten
> Grundlagen der Programmierung in C beibringen. Es gibt sogar
> Leute, die mitarbeiten, lernen und tatsächlich gute Programme
> zustande bringen (mein Favorit bisher war eine Gruppe, die alle
> Sortieralgorithmen aus dem Theorie-Script implementiert und
> gegeneinander antreten lassen hat :-) Ob der Prozentsatz solcher
> Leute höher oder niedriger als bei Java/Pascal/Perl/Haskell/...
> ist, mag ich nicht beurteilen.
Von einem Programmierkurs in Modula2, den ich mal mitgemacht hatte,
kann ich nur sagen, dass solcher Fleiss nicht bei jedem Korrektor
auf Gegenliebe stoesst (fuehrt das doch manchem Korrektor evt. vor
Augen, wie viel *weniger* er doch ueber die Sprache weiss, als seine
Schuetzlinge ...).
Juergen Ilse
Carsten Krueger <usenet23.e...@neverbox.com> wrote:
> tobia...@web.de (Tobias Bell) wrote:
>>4) malloc muss gecastet werden
>>int *p = (int*)malloc(5*sizeof(int))
> Warum denn auch nicht?
Weil der cast bei einem C89/C90 Compiler evt. einen fehlenden Prototyp
fuer malloc "verdeckt" (Default-Return-Typ ist dort "int") ...
>>10) Es gibt nur printf. printf("%s", "blabla") ist besser als
>>puts("blabla");
> gets will man nicht benutzen, also währe es konsequent auch puts nicht
> zu benuzen.
Wegen des aehnlichen Namens der Funktion? Das ist ja wohl Bloedsinn.
gets() hat ein Problem als Kandidat fuer "bufferoverflow-Schwachstellen".
Diese Schwachstellen gibt es in puts() nicht, also gibt es exakt *gar*
*keinen* Grund auf puts() zu verzichten (im Gegensatz zu gets()).
Aber selbst wenn waere die Begruendung fuer printf Kaese: Man koennte
ja fputs() verwenden um auf stdout zu schreiben, waere auch nicht printf()
und hat genausowenig bufferoverflow-Probleme wie fgets() ...
Ausserdem wuerde das dafuer sprechen, auf printf zu verzichten (weil i
scanf() unvorsichtig verwendet auch ein potentieller Schwachpunkt wg,
Bufferoverflow ist ...).
Juergen Ilse
Ich wollte dir gerade widersprechen, und habe mich entschlossen, die
Sache doch erst noch einmal mit dem gcc zu testen ...
Ist das eigentlich jetzt ein Fehler im gcc?
------------------- bla.c -----------------------
#include <stdio.h>
#ifdef MIT_TYPE_BLA
typedef unsigned char bla;
#endif
int main(void)
{
#ifdef MIT_VAR_BLA
long bla;
printf("Groesse von Variable bla: %d\n", sizeof bla);
#endif
#ifdef MIT_TYPE_BLA
printf("Groesse von Typ bla: %d\n", sizeof(bla));
#endif
return 0;
}
-------------------------------------------------
~ $ gcc -DMIT_VAR_BLA -Wall -W -pedantic -ansi -o bla bla.c
~ $ ./bla
Groesse von Variable bla: 4
~ $ gcc -DMIT_TYPE_BLA -Wall -W -pedantic -ansi -o bla bla.c
~ $ ./bla
Groesse von Typ bla: 1
~ $ gcc -DMIT_TYPE_BLA -DMIT_VAR_BLA -Wall -W -pedantic -ansi -o bla bla.c
~ $ ./bla
Groesse von Variable bla: 4
Groesse von Typ bla: 4
-------------------------------------------------
Sprich wenn es *sowohl* eine Variable *als* *auch* einen Typ namens
bla gibt, muss dann der Compiler als Ergebnis von sizeof(bla) nicht
*immer* die Groesse des Typs zurueckliefern? gcc tut das zumindest
nicht sondern liefert in dem Fall (wie man oben sehen kann) immer
die Groesse der Variablen. Ist das ein Bug oder nicht?
Getestet habe ich das mit diesen 3 gcc-Versionen:
-------------------------------------------------~ $ /opt/sfw/bin/gcc -v
Reading specs from /opt/sfw/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/specs
gcc version 2.95.3 20010315 (release)
Reading specs from /opt/gnu/lib/gcc-lib/sparc-sun-solaris2.8/3.2.2/specs
Configured with: ../gcc-3.2.2/configure --prefix=/opt/gnu --with-gnu-ld --with-ld=/opt/gnu/bin/ld --with-gnu-as --with-as=/opt/gnu/bin/as --enable-threads=solaris
Thread model: solaris
gcc version 3.2.2
Reading specs from /usr/lib/gcc-lib/i486-suse-linux/3.3.2/specs
Konfiguriert mit: ../gcc-3.3.2/configure --prefix=/usr --build=i486-suse-linux --host=i486-suse-linux
Thread model: posix
gcc-Version 3.3.2
Falk Hueffner
> ------------------- bla.c -----------------------
> #include <stdio.h>
>
> #ifdef MIT_TYPE_BLA
> typedef unsigned char bla;
> #endif
>
> int main(void)
> {
> #ifdef MIT_VAR_BLA
> long bla;
> printf("Groesse von Variable bla: %d\n", sizeof bla);
> #endif
> #ifdef MIT_TYPE_BLA
> printf("Groesse von Typ bla: %d\n", sizeof(bla));
> #endif
> return 0;
> }
> -------------------------------------------------
> ~ $ gcc -DMIT_TYPE_BLA -DMIT_VAR_BLA -Wall -W -pedantic -ansi -o bla bla.c
> ~ $ ./bla
> Groesse von Variable bla: 4
> Groesse von Typ bla: 4
> -------------------------------------------------
> Sprich wenn es *sowohl* eine Variable *als* *auch* einen Typ namens
> bla gibt, muss dann der Compiler als Ergebnis von sizeof(bla) nicht
> *immer* die Groesse des Typs zurueckliefern?
Meines Erachtens gelten hier die ueblichen Scoping-Regeln, das heisst,
es koennengar nicht gleichzeitig ein Typ und eine Variable "bla"
sichtbar sein, und die Frage stellt sich nicht.
--
Falk
Harald Wenninger
>> The stream stderr is unbuffered. The stream stdout is line-buffered when
>> it points to a terminal.
> Das heisst, das stderr auf dem System, auf dem das die Beschreibung
> von stderr ist, ungepuffert ist. IIRC besagt das der Sprachstandard
> aber nicht, also kann stderr auch "line-buffered" sein ohne den Standard
> zu verletzen. aus 7.19.3 (unter Punkt 7):
> ------------------------------
> As initially opened, the standard error stream is not fully buffered;
> the standard input und standard output streams are fully buffered if
> and only if the stream can be determined not to refer to an interactive
> device.
> ------------------------------
Ich dachte nur, weil unten in der manpage "conforming to ANSI C" stand. Dass
der Standard hier "weicher" ist, wusste ich nicht.
Gruß,
Harald
--
Ash nazg durbatulūk, ash nazg gimbatul,
ash nazg thrakatulūk agh burzum-ishi krimpatul.
Juergen Ilse
Alexander Bartolich <alexander...@gmx.at> wrote:
> begin Juergen Ilse:
>> Bei dieser Zeile haette ich vermutlich ein "if (p == NULL)"
>> geschrieben, aber ich weiss, dass das eher Geschmacksache ist ...
> NULL considered harmful.
In diesem Fall nicht. Hier benoetige ich eine "Nullpointerkonstante"
und NULL ist garantiert eine solche (und gibt im Quelltext den Hinweis,
dass es sich nicht zwingend um den integer-Wert 0 handeln *muss* aber
sehr wohl kann, denn auch die integer 0 erfuellt bekanntlich die Defi-
nition der Nullpointerkonstante). Durch den Vergleich mit NULL mache
ich im Quelltext deutlich, dass ich einen Pointer auf Nullpointer
pruefen moechte, und das wird IMHO beim ueberfliegen leichter deut-
lich, als durch das "if(!p)". Das mag Geschmacksache sein, aber mir
faellt es beim Vergleich mit NULL in diesem Fall leichter den Sinn
zu erfassen (ich kann den Sinn *schneller* erfassen).
Juergen Ilse
Dann fuege vor der Definition von Variable bla noch ein
bla blubb;
ein. Der Typ bla und die Variable bla sind dann beide im selben scope
(in der Funktion main) verwendet. Es gibt weder Warnungen noch Fehler-
meldungen. Fehlermeldungen gibt es allerdings, wenn man anschliessend
die Definition der Variablen blubb (vom Typ bla) *hinter* die Definition
der Variablen bla verschiebt ... Irgendwie sieht mir das (insbesondere
nach meinem Test von eben mit der hinzugefuegten Variable vomn Typ bla
in der funktion main) nach einem Compiler-Bug aus. Weiss wer was naeheres
oder kann mich vielleicht mal mit der Nase auf die relevante Stelle des
Standards stossen?
Roman Racine
> Dann fuege vor der Definition von Variable bla noch ein
>
> bla blubb;
>
> ein. Der Typ bla und die Variable bla sind dann beide im selben scope
> (in der Funktion main) verwendet.
Der Identifier bla wird aber verdeckt durch die neue Deklaration von int
bla. Das steht so in den Scoping Regeln des Standards. Deswegen geht auch
int bla;
bla blubb;
nicht, da der Typ bla nicht mehr sichtbar ist.
Gruss
Roman
Alexander Bartolich
> [...] Durch den Vergleich mit NULL mache ich im Quelltext deutlich,
> dass ich einen Pointer auf Nullpointer pruefen moechte,
a) if (!p)
b) if (p == 0)
c) if (p == (void*)0)
d) if (p == (int*)0)
e) if (p == NULL)
> und das wird IMHO beim ueberfliegen leichter deutlich,
> als durch das "if(!p)".
Ich bevorzuge b). Variante e) entspricht entweder b) oder c).
Es ist zum einen schön, dass es in C mehr als eine Schreibweise gibt.
Aber IMHO ist es nicht gut, sich durch idealisierte Bezeichner zu
weit von der rauhen Wirklichkeit zu entfernen.
Falk Hueffner
> a) if (!p)
> b) if (p == 0)
> c) if (p == (void*)0)
> d) if (p == (int*)0)
> e) if (p == NULL)
>
> > und das wird IMHO beim ueberfliegen leichter deutlich,
> > als durch das "if(!p)".
>
> Ich bevorzuge b).
Davon wuerde ich eher abraten, denn diese Schreibweise habe ich noch
nie gesehen, und wuerde deswegen sofort an einen Integer-Vergleich
denken. Ich muesste erst den Typ von p sehen, um meinen Irrtum zu
bemerken.
> Variante e) entspricht entweder b) oder c). Es ist zum einen schön,
> dass es in C mehr als eine Schreibweise gibt.
Findest du? Merkwuerdig, ich empfinde das als Nachteil; waere es nicht
so, koennten wir uns diese Diskussion sparen.
> Aber IMHO ist es nicht gut, sich durch idealisierte Bezeichner zu
> weit von der rauhen Wirklichkeit zu entfernen.
Das kapiere ich nicht.
--
Falk
Ullrich von Bassewitz
> Weil der cast bei einem C89/C90 Compiler evt. einen fehlenden Prototyp
> fuer malloc "verdeckt" (Default-Return-Typ ist dort "int") ...
Irgendwie kann ich das Argument bald nicht mehr hoeren ... Wenn jemand seinen
Compiler nicht so konfiguriert hat, dass er in diesem Falle warnt, dann hat
dieser Jemand noch einen ganzen Sack anderer Probleme, und dann kommt's auf
den Cast mehr oder weniger nicht an:-)
Gruss
Uz
--
Ullrich von Bassewitz u...@spamtrap.musoftware.de
00:01:17 up 11 days, 7:26, 11 users, load average: 0.40, 0.16, 0.31
Bodo Thiesen
>tobia...@web.de (Tobias Bell) writes:
>>1) Schreibt in den Kommentar bei der Angabe der Sprache nicht etwa
>>`ISO C90', das ist falsch. Man schreibt einfach C hin.
>
> Nach "ISO/IEC 9899:1999 (E)" ist der Name der
> Programmiersprache "C" und nicht "ISO C90".
>
> This International Standard specifies the form and
> establishes the interpretation of programs written
> in the C programming language. (...)
>
>> Es gibt ja nur
>>_ein_ C. (Niemand kennt ISO C99)
>
> Alle früheren Ausgaben sind ungültig.
>
> This second edition cancels and replaces the first
> edition, ISO/IEC 9899:1990, as amended and corrected
> by ISO/IEC 9899/COR1:1994, ISO/IEC 9899/AMD1:1995, and
> ISO/IEC 9899/COR2:1996. (...)
Wenn ich heute ein Programm in C schreibe, wird es in 10 Jahren ggf.
kein gültiges C Programm mehr sein, weil C etwas sehr variables ist.
Also schreibe ich sinnvollerweise C99 und nicht C in den Kommentar.
Gruß, Bodo
--
MS Outlook Express?->[DE: http://piology.org/ILOVEYOU-Signature-FAQ.html]
@@@@@ GEGEN TCG aka. TCPA: @@@@@ [DE: http://www.againsttcpa.com]
Bodo Thiesen
>Claus Reibenstein schrieb:
>>>>
>>>>char c = (char*) malloc(5*sizeof(char))
>>>
>>>Korrekt.
>>
>> Du brauchst auch eine Ausbildung ...
>>
>> Gruß. Claus
>>
>Ups, hab ich doch glatt den Fehler übersehen:
>
>char *pc = (char*) malloc(5*sizeof(char));
Du brauchst wirklich eine Ausbildung!
Bodo Thiesen
>Claus Reibenstein <c.reib...@pop-hannover.de> wrote:
>>>>4) malloc muss gecastet werden
>>>>
>>>>int *p = (int*)malloc(5*sizeof(int))
>>>
>>> Schadet wenigstens nichts.
>
>> Es sei denn, man vergisst, die <stdlib.h> zu #includen (ich liebe diese
>> "Sprache"). Und nach dem, was ich hier gelesen habe, gehe ich mal davon
>> aus, dass dem Ausbilder genau das passiert ist, weshalb er eine
>> Fehlermeldung bekommen und diesen Fehler durch den Cast "korrigiert" hat.
>
>Das vergessen von <stdlib.h> ist imho kein Argument. Wer seinen Compiler
>so einstellt das er bei "vergessen" des include nicht trotzdem eine
>Warnung bekommt gehört sowieso gevierteilt. :-)
>
>Aber du hast recht. Bringen tut der cast in dem Fall nichts.
Du braucht offensichtlich auch eine Ausbildung.
Bodo Thiesen
>* Juergen Ilse tat kund und zu wissen:
>
>>> The stream stderr is unbuffered. The stream stdout is line-buffered when
>>> it points to a terminal.
>> Das heisst, das stderr auf dem System, auf dem das die Beschreibung
>> von stderr ist, ungepuffert ist. IIRC besagt das der Sprachstandard
>> aber nicht, also kann stderr auch "line-buffered" sein ohne den Standard
>> zu verletzen. aus 7.19.3 (unter Punkt 7):
>> ------------------------------
>> As initially opened, the standard error stream is not fully buffered;
>> the standard input und standard output streams are fully buffered if
>> and only if the stream can be determined not to refer to an interactive
>> device.
>> ------------------------------
>
>Ich dachte nur, weil unten in der manpage "conforming to ANSI C" stand. Dass
>der Standard hier "weicher" ist, wusste ich nicht.
Das heißt nur, daß die Funktion standardkonform ist, nicht, daß alles, was
die Funktion macht, exakt SO vom Standard vorgeschrieben wird.
Bodo Thiesen
>Alexander Busch wrote:
>
>>(Wobei aber auch einige Programme mit ihren "Fehlermeldung" nicht
>>geizen... z.B. "Low CPU detected, switching to emulation..." sehe ich
>>nicht wirklich als Fehler der nach stderr gehört.)
>
>ACK. Das ist kein Fehler. Die zugehoerige Ausgabe gehoert nach
>stddiag.
Wo kann ich beantragen, daß mein stddbg offiziell in den Standard
aufgenommen wird? (stddbg als ein Kanal, der in den meisten Fällen
sämtliche Ausgaben stillschweigend schluckt, der aber so konstruiert
ein soll, daß man die Ausgaben (von außen gesteuert) doch irgendwohin
bekommen kann...)
Bodo Thiesen
>Tobias Bell <tobia...@web.de> wrote:
>> if(foo)
>> {
>
>> }
>
>Du hast das wichtigste vergessen: im Editor Tab-Size = 4
>einstellen, damit wirklich niemand auf die Idee kommt, den Kot
>mit etwas anderem als MSVC anzusehen.
Bringt nix. Ich habe mir bereits angewöhnt, jeden fremden Quelltext als
allererstes mal durch indent zu jagen ...
Bodo Thiesen
>Hallo,
>
>Tobias Bell <tobia...@web.de> wrote:
>> habt ihr schon mal eine Ausbildung im IT-Bereich genossen und dabei
>> die Sprache C lernen dürfen? Ja, und habt ihr euch darüber geärgert,
>> dass man euch Fehler anstreicht, die keine sind? Dann jetzt die
>> ultimativen Tips um dies zu umgehen.
>
>Wenn ich deine Auflistung so lese, kommt in mir der Verdacht auf, dass
>viele der "Fehler die keine sind", auf die du dich beziehst, wirkliche
>Fehler sind ...
Juergen, Du hast Tobias genau falsch verstanden. Laut seiner Aussage
würde
begin 644 cls.c
/*
* Language: ISO C99
*
* Tested compiler: gcc 3.2.1
*
* Test system: SuSE Linux 7.3 (kernel 2.4.20-e2compr-kdbg-ptrace)
*/
#include <stdio.h>
#include <stdlib.h>
int main(void) {
char * x;
int i;
x = malloc(100);
if (!x) {
fprintf(stderr,"Blök!\n");
return EXIT_FAILURE;
}
sprintf("%98s\n","");
for (i=0;i<100;++i)
puts(x);
free(x);
return EXIT_SUCCESS;
}
end
als das fehlerhafteste Programm angesehen, das überhaupt existiert,
obwohl es absolut korrekt ist (hoffe ich ...).
>Wenn diese "Tips" vom Dozenten kamen (bzw. er die Einhaltung erwartet
>hat), ist das verstaendlich. Ansonsten sollte man bei jedem *solchen*
>Fehler, den der Dozent angestrichen hat, dazu uebergehen, ihm seinen
>Irrtum anhand des C-Standards zu *belegen* und sich notfalls bei seinem
>Vorgesetzten beschweren.
Das kann man machen - klar, aber wie wird dann in ein paar Monaten die
Prüfung für einen ausfallen?
Juergen Ilse
Du hast recht (und ich habe inzwischen im standard nachgelesen, dass
typedef-Namen und Variablennamen in d er Tat im selben Namespace liegen
und sich gegenseitig ins Gehege kommen muessten, wenn sie im selben scope
sichtbar sind). Ich habe mich dadurch verwirren lassen, dass in main()
im selben scope wie die Variablendeklaration bla die Typdefinition
durchaus noch benutzt werden kann, um Variablen zu definieren, aller-
dings (und das hatte ich nicht gleich probiert) nur, solange diese
*vor* der Definition der Variablen bla stehen. Solange die Variable
bla noch nicht vereinbart wurde, ist also der typedef noch sichtbar,
auch, wenn die Variable im selben scope vereinbart wird. Sobald die
Variable vereinbart wurde, ist damit (fuer den Sichtbarkeitsbereich
der Variablen) der typedef unsichtbar ...
Fazit: doch kein Bug in gcc.
Wobei es schon aehnliche, lange Zeit unbemerkte, Bugs im gcc bzgl.
Sichtbarkeit von Variablen gegeben hatte. Folgendes Prograemmchen
wurde ueber viele gcc-Versionen hinweg falsch uebersetzt, ich weiss
nicht mehr, ab welcher Version es korrigiert wurde:
-----------------------------------------------------
#include <stdio.h>
int var=1;
int main(void)
{
int var=2;
{
extern int var;
printf("Wert von globalem var: %d\n", var);
}
return 0;
Alexander Bartolich
> Davon wuerde ich eher abraten, denn diese Schreibweise habe
^^^
http://www-info2.informatik.uni-wuerzburg.de/dclc-faq/kap1.html
Aber du hast bestimmt nur dieses eine Kapitel noch nie gesehen...
>> Es ist zum einen schön, dass es in C mehr als eine Schreibweise
>> gibt.
>
> Findest du? Merkwuerdig, ich empfinde das als Nachteil; waere es
> nicht so, koennten wir uns diese Diskussion sparen.
Wer als einziges Werkzeug einen Hammer besitzt, für den sieht jedes
Problem aus wie ein Nagel. IMHO wirk eine Sprache, die in sich
pluralistisch ist, dem effektiv entgegen.
>> Aber IMHO ist es nicht gut, sich durch idealisierte Bezeichner
>> zu weit von der rauhen Wirklichkeit zu entfernen.
>
>Das kapiere ich nicht.
http://www-info2.informatik.uni-wuerzburg.de/dclc-faq/kap1.html#1.3
Bei einem
#define NULL 0
sieht
int p = NULL;
zwar seltsam aus, passiert aber den Compiler ohne Widerstände.
Und dummerweise ist diese Definition kein Legacy sondern die einzig
mögliche in C++.
Selbst ohne pathologische Fälle wie die Übergabe von Funktionszeigern
über Ellipsen bei sizeof(void*) != sizeof(void(*)()) täuscht NULL
Klarheit vor, wo keine besteht.
Carsten Krueger
>als das fehlerhafteste Programm angesehen, das überhaupt existiert,
>obwohl es absolut korrekt ist (hoffe ich ...).
Korrekt schon, schön nicht.
$ gcc -Wall -pedantic -ansi test.c
test.c: In function `main':
test.c:23: warning: zero-length format string
$ splint test.c
Splint 3.1.1 --- 02 May 2003
test.c: (in function main)
test.c:23:2: Buffer overflow possible with sprintf. Recommend using
snprintf
instead: sprintf
Use of function that may lead to buffer overflow. (Use
-bufferoverflowhigh to
inhibit warning)
test.c:23:10: Function call may modify observer: "%98s\n"
Storage declared with observer is possibly modified. Observer
storage may not
be modified. (Use -modobserver to inhibit warning)
test.c:23:10: Storage becomes observer
test.c:26:8: Passed storage x not completely defined (*x is
undefined):
puts (x)
Storage derivable from a parameter, return value or global is not
defined.
Use /*@out@*/ to denote passed or returned storage which need not be
defined.
(Use -compdef to inhibit warning)
test.c:16:2: Storage *x allocated
test.c:26:3: Return value (type int) ignored: puts(x)
Result returned by function call is not used. If this is intended,
can cast
result to (void) to eliminate message. (Use -retvalint to inhibit
warning)
Finished checking --- 4 code warnings
--
http://learn.to/quote - richtig zitieren
http://www.realname-diskussion.info - Realnames sind keine Pflicht
http://oe-faq.de/ - http://www.oe-tools.de.vu/ - OE im Usenet
http://www.spamgourmet.com/ - Emailadresse(n) gegen Spam
Vinzent 'Gadget' Hoefler
>Wo kann ich beantragen, daß mein stddbg offiziell in den Standard
>aufgenommen wird?
Ja, was denn? Habt ihr kein Sprachkonsortium, bei dem man solche
Vorschlaege bringen kann?
Vinzent.
Juergen Ilse
Falk Hueffner <falk.h...@student.uni-tuebingen.de> wrote:
> alexander...@gmx.at (Alexander Bartolich) writes:
>> a) if (!p)
>> b) if (p == 0)
>> c) if (p == (void*)0)
>> d) if (p == (int*)0)
>> e) if (p == NULL)
>>
>> > und das wird IMHO beim ueberfliegen leichter deutlich,
>> > als durch das "if(!p)".
>>
>> Ich bevorzuge b).
> Davon wuerde ich eher abraten, denn diese Schreibweise habe ich noch
> nie gesehen, und wuerde deswegen sofort an einen Integer-Vergleich
> denken.
Woran du dabei denkst, ist erst einmal zweitrangig. Die Zeile ist
korrekt und leistet das gewuenschte (Vergleich mit Nullpointer).
0 ist eine "Nullpointerkonstante", und zwar auch dann, wenn sie
nicht nach (void*) gecastet wurde.
> Ich muesste erst den Typ von p sehen, um meinen Irrtum zu bemerken.
Aus diesem Grund bevorzuge ich den Vergleich mit NULL, denn NULL hat
ebenfalls eine Nullpointerkonstante zu sein, nur im Gegensatz zu 0
eine, der man eher ansieht "hier ist ein Pointer gemeint". Gegen c)
spricht IMHO, dass es sich (fuer mich) nicht ganz so fluessig liest
wie b) oder e). d) ist IMHO (je nachdem, welchen Typ nun p genau hat)
u.U. auch manchmal flacsh (in dem diskutierten Beispiel aber IIRC
nicht,weil p dort ein (int*) war). Bei Verwendung von NULL sollte
man sich aber darueber im klaren sein, dass an manchen Stellen (z.B.
als Parameter eienr Funktion mit variabler Parameterliste) ggfs. auf
den Typ (void*) gecastet werden muss, denn der Standard laesst als
Typ von 0 sowohl einen integer-Typ als auch (void*) zu ...
Bernd Laengerich
> unter DOS und war dort trotz der etwas eingeschraenkten Moeglichkeiten
> sinvoll:
> if %errorlevel% = 1 goto fehler
Nur um mal herumzustänkern ;-)
Syntaktisch korrekt unter DOS ist
if ERRORLEVEL 1 goto fehler
Dabei wird geprüft, ob der Rückgabewert des Programmes größer/gleich 1
ist. Erst Erweiterungen wie 4DOS und später dann in der DOS-Emulation
unter NT brachten den echten Vergleich.
Seinerzeit hatte ich ein Riesen-Batch, um den Rückgabewert in eine
Variable zu packen...
Bernd
Falk Hueffner
> begin Falk Hueffner:
> > Davon wuerde ich eher abraten, denn diese Schreibweise habe
> > ich noch nie gesehen, [...]
> ^^^
> http://www-info2.informatik.uni-wuerzburg.de/dclc-faq/kap1.html
>
> Aber du hast bestimmt nur dieses eine Kapitel noch nie gesehen...
Das ist kein realer Code, sondern ein Lehrbeispiel.
> >> Es ist zum einen schön, dass es in C mehr als eine Schreibweise
> >> gibt.
> >
> > Findest du? Merkwuerdig, ich empfinde das als Nachteil; waere es
> > nicht so, koennten wir uns diese Diskussion sparen.
>
> Wer als einziges Werkzeug einen Hammer besitzt, für den sieht jedes
> Problem aus wie ein Nagel. IMHO wirk eine Sprache, die in sich
> pluralistisch ist, dem effektiv entgegen.
Es ging aber nicht um Werkzeuge, sondern um Schreibweisen, mit
vollkommen identischer Semantik.
> Bei einem
>
> #define NULL 0
>
> sieht
>
> int p = NULL;
>
> zwar seltsam aus, passiert aber den Compiler ohne Widerstände.
Kein ernstzunehmenden Compiler definiert NULL auf 0. Und dass man mit
einem Konstrukt Unfug machen kann, ist meist ein ziemlich muedes
Argument gegen seinen generellen Einsatz.
> Und dummerweise ist diese Definition kein Legacy sondern die einzig
> mögliche in C++.
Das interessiert hier nicht besonders.
> Selbst ohne pathologische Fälle wie die Übergabe von
> Funktionszeigern über Ellipsen bei sizeof(void*) !=
> sizeof(void(*)()) täuscht NULL Klarheit vor, wo keine besteht.
s.o.
--
Falk
Juergen Ilse
Bernd Laengerich <Bernd.La...@web.de> wrote:
> Juergen Ilse wrote:
>> unter DOS und war dort trotz der etwas eingeschraenkten Moeglichkeiten
>> sinvoll:
>> if %errorlevel% = 1 goto fehler
> Nur um mal herumzustänkern ;-)
> Syntaktisch korrekt unter DOS ist
> if ERRORLEVEL 1 goto fehler
Stimmt, es ist nur schon etwas zu lange her, dass aich das gebraucht
haette (frueher war ich mal einigermassen fit in command.com, heutzu-
tage brauche ich das nur noch selten bis gar nicht, da ich mehr mit
"unixoiden" Systemen zu tun habe).
> Dabei wird geprüft, ob der Rückgabewert des Programmes größer/gleich 1
> ist. Erst Erweiterungen wie 4DOS und später dann in der DOS-Emulation
> unter NT brachten den echten Vergleich.
> Seinerzeit hatte ich ein Riesen-Batch, um den Rückgabewert in eine
> Variable zu packen...
Stimmt, der Vergleich war immer auf "groesser oder gleich" ausgerichtet.
Trotzdem war und ist aber der exit-Status eines Programms auch unter
Windows abrufbar und (wichtig1) *sinnvoll* *benutzbar*.
Michael Stricker
> Was für eine Ausbildung hast du denn genossen. Ich lege gerade die
> Prüfung zum "Mathematisch-technischen Assistenten/Informatik
> (IHK)"(TM) ab bzw. schreibe nächste Woche die Prüfungen. Gott sei
> gelobt und gedankt, dass das keine berufsschulpflichtige Ausbildung
> ist.
Daß war nach meinem gescheiterten Informatik-Studium an der Schule für DV in
Würzburg, 1992-1995. Alles nur Cobol-Lehrer, von C hatte keiner eine Ahnung,
Pointer wurden nicht gelehrt und durften auch nicht verwendet werden, usw.
> Sonst hätte ich mich bestimmt schon selbst entleibt. Die Trainer
> sind auch lernfähig und lassen sich sogar Nachhilfe in C geben.
Tja, war bei uns nicht der Fall, vor allen Dingen Reihenfolge von Operatoren
war ein beliebiges Zankthema, aber den Lehrern konnte man wenigstens per Code
direkt nachweisen, daß ihre Prüfungsaufgaben unsinnig sind (was bei der IHK
Prüfung leider nicht möglich war), und gerade ich in Progammieren eine 4
bekommen hatte ;-) (seltsamer war ich immer in der Klasse der einzigste, dessen
Programme gelaufen sind und nach den Specs funktioniert hatten ;-) ).
> Sind
> aber in algorithmischen Dingen recht fit. Wenn ich da immer das
> Wehklagen der Fach-Infs höre ... Jetzt müßte ich nur noch die
> IHK-Prüfer dazu bekehren sich mal den C-Standard näher zu betrachten.
Na ja, das einzige, was ich dort neues gelernt hatte, war der Gruppenwechsel.
Computertechnisch war alles andere Käse. Aber das Betriebswirtschaftliche
KnowHow war dort dagegen sehr gut.
> Was solls zur Not schreibe ich halt Müll-Code. Ist ja keine Religion
> hier.
Hauptsache, Du schreibst so einen Müll nicht im Berufsleben oder privat.
gruß
Michael
Claus Reibenstein
> Bodo Thiesen <bot...@gmx.de> wrote:
>
>>>>>>int *p = (int*)malloc(5*sizeof(int))
>
>>>Aber du hast recht. Bringen tut der cast in dem Fall nichts.
>
>>Du braucht offensichtlich auch eine Ausbildung.
>
> Du bist der Meinung das der cast was "bringt"?
> Was denn?
Er lässt die Fehlermeldung verschwinden.
Gruß. Claus
Claus Reibenstein
> Jirka Klaue <jkl...@ee.tu-berlin.de> wrote:
>
>>Ralf Bartzke wrote:
>>
>>>"In C++ ist sizeof(char) = 1"
Korrekt.
>> "In C ist sizeof(char) == 1".
Korrekt.
> C++: sizeof 'a' == 1
> C: sizeof 'a' == sizeof(int)
Korrekt.
Gruß. Claus
Claus Reibenstein
> ACK. Das ist kein Fehler. Die zugehoerige Ausgabe gehoert nach
> stddiag.
Gibt es im Standard nicht.
Gruß. Claus
Claus Reibenstein
> Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
>
>>Weil der cast bei einem C89/C90 Compiler evt. einen fehlenden Prototyp
>>fuer malloc "verdeckt" (Default-Return-Typ ist dort "int") ...
>
> Irgendwie kann ich das Argument bald nicht mehr hoeren ... Wenn jemand seinen
> Compiler nicht so konfiguriert hat, dass er in diesem Falle warnt, dann hat
Es gibt Compiler, die man so einstellen kann? Welche denn?
Gruß. Claus
Claus Reibenstein
> ------------------- bla.c -----------------------
> #include <stdio.h>
>
> #ifdef MIT_TYPE_BLA
> typedef unsigned char bla;
> #endif
>
> int main(void)
> {
> #ifdef MIT_VAR_BLA
> long bla;
> printf("Groesse von Variable bla: %d\n", sizeof bla);
> #endif
> #ifdef MIT_TYPE_BLA
> printf("Groesse von Typ bla: %d\n", sizeof(bla));
> #endif
> return 0;
> }
> -------------------------------------------------
> ~ $ gcc -DMIT_TYPE_BLA -DMIT_VAR_BLA -Wall -W -pedantic -ansi -o bla bla.c
LCC-Win32 meint dazu:
Warning d:\ctest\ctest.c: 13 redefinition of bla
Error d:\ctest\ctest.c: 14 illegal use of type name `bla'
Gruß. Claus
Vinzent 'Gadget' Hoefler
gcc -Wbad-function-cast
Vinzent.
Vinzent 'Gadget' Hoefler
Naja. Dein Ironiedetektor wird dort zum Glueck ja auch nicht erwaehnt.
Vinzent.
Roland Damm
Claus Reibenstein hat geschrieben:
> > C: sizeof 'a' == sizeof(int)
>
> Korrekt.
Gibt es in C eigentlich irgend eine Möglichkeit,
Ganzzahlvariablem mit definierter Bit-Zahl zu definieren? Ich
meine das ist doch so ein Standartproblem, daß ein int keine
auf allen Systemen gleiche Länge hat. Es muß ja nicht gleich
sein, daß jedes System mit jeder Bitzahl klar kommen muß, aber
sowas wie int_16 wäre doch praktisch - entweder gibt es
16bit-Integer oder beim Compilieren gibt's Fehlermeldungen.
Aber diese Undefiniertheit ist doch IMO absolut grausig. Da
heist es, man solle int's verwenden aber niemand sagt einem,
auf welchen Wertebeich und Speicherbedarf man sich verlassen
kann.
CU Rollo
--
Hier entsteht in Kürze eine neue Sig-Präsenz.
Vinzent 'Gadget' Hoefler
>Ganzzahlvariablem mit definierter Bit-Zahl zu definieren?
Jein.
>Ich
>meine das ist doch so ein Standartproblem, daß ein int keine
>auf allen Systemen gleiche Länge hat.
Ja. Es gibt aber fuer jeden Typen einen definierten Mindestbereich,
zumindest auf diesen kann man sich verlassen.
>Es muß ja nicht gleich
>sein, daß jedes System mit jeder Bitzahl klar kommen muß, aber
>sowas wie int_16 wäre doch praktisch - entweder gibt es
>16bit-Integer oder beim Compilieren gibt's Fehlermeldungen.
<URL:http://www.opengroup.org/onlinepubs/007904975/basedefs/stdint.h.html>
>Aber diese Undefiniertheit ist doch IMO absolut grausig. Da
>heist es, man solle int's verwenden aber niemand sagt einem,
>auf welchen Wertebeich und Speicherbedarf man sich verlassen
>kann.
Doch, der Sprach-Standard. Er legt entsprechende Grenzen fest.
Vinzent.
Falk Hueffner
> Gibt es in C eigentlich irgend eine Möglichkeit,
> Ganzzahlvariablem mit definierter Bit-Zahl zu definieren?
#include <stdint.h>
uint16_t x;
Theoretisch muss es die Typen allerdings nicht geben, koennte ja sein,
dass der Compiler gar keinen 16-bit Typ hat.
--
Falk
Wolfgang Kaufmann
Hallo,
gcc.
Wolfgang.
--
"Es gibt Dinge, die man bereut, ehe man sie tut. Und man tut sie doch."
-- Christian Friedrich Hebbel
Juergen Ilse
Falk Hueffner <falk.h...@student.uni-tuebingen.de> wrote:
> Kein ernstzunehmenden Compiler definiert NULL auf 0.
Du irrst. Das ist viel gebraeuchlicher als du vielleicht denkst, und in
*guten* Buechern wird auch auf die damit verbundenen Gefahren hingewiesen
(wenn NULL in einer Ellipse verwendet wird, *muss* auf den passenden Tyap
gecastet werden, um portablen Code zu erhalten).
Falk Hueffner
> Falk Hueffner <falk.h...@student.uni-tuebingen.de> wrote:
> > Kein ernstzunehmenden Compiler definiert NULL auf 0.
>
> Du irrst. Das ist viel gebraeuchlicher als du vielleicht denkst,
Welcher tut das denn?
--
Falk
Claus Reibenstein
Dein Ironieindikator scheint auch nicht gerade das Gelbe vom Ei zu sein ...
Gruß. Claus
Claus Reibenstein
> Claus Reibenstein wrote:
>
>>Es gibt Compiler, die man so einstellen kann? Welche denn?
>
> gcc -Wbad-function-cast
Ah ja. Und damit bekommt man dann eine Warnung, wenn man böse[tm]
Funktionen wie gets benutzt. Interessant. Hätte ich auf Grund der
Namensgebung dieser Option gar nicht vermutet ...
Gruß. Claus
Vinzent 'Gadget' Hoefler
>Vinzent 'Gadget' Hoefler schrieb:
>
>> gcc -Wbad-function-cast
>
>Ah ja. Und damit bekommt man dann eine Warnung, wenn man böse[tm]
>Funktionen wie gets benutzt.
-ECONTEXT. Der Zusammenhang war hier
<news:3fb3c1b0$0$12053$a5ec...@news.ilse.asys-h.de> ff.:
|Weil der cast bei einem C89/C90 Compiler evt. einen fehlenden Prototyp
|fuer malloc "verdeckt" (Default-Return-Typ ist dort "int") ...
Was nicht gerade viel mit gets zu tun zu haben scheint, oder?
Vinzent.
Alexander Bartolich
> Das ist aber nur in C++ legal.
http://www-info2.informatik.uni-wuerzburg.de/dclc-faq/kap1.html#1.3
# Die Sprachbeschreibung definiert den Begriff Null-Zeiger-Konstante
# als konstanten integralen Ausdruck mit dem Wert 0, oder einen
# entsprechenden Ausdruck, dessen Typ nach (void *) umgewandelt
# wurde.
Claus Reibenstein
>>Du irrst. Das ist viel gebraeuchlicher als du vielleicht denkst,
>
> Das ist aber nur in C++ legal.
Falsch.
Gruß. Claus
Claus Reibenstein
> Claus Reibenstein <c.reib...@pop-hannover.de> wrote:
>
>>>>Weil der cast bei einem C89/C90 Compiler evt. einen fehlenden Prototyp
>>>>fuer malloc "verdeckt" (Default-Return-Typ ist dort "int") ...
>>>
>>>Irgendwie kann ich das Argument bald nicht mehr hoeren ... Wenn jemand seinen
>>>Compiler nicht so konfiguriert hat, dass er in diesem Falle warnt, dann hat
>
>>Es gibt Compiler, die man so einstellen kann? Welche denn?
>
> Fast(?) alle.
>
> gcc -Wall zum Beispiel:
> warning: implicit declaration of function `malloc'
Falsche Baustelle. Mir ging es um die Verwendung böser[tm] Funktionen
wie gets.
Mein Fehler.
Gruß. Claus
Andreas Burmester
>Juergen Ilse <jue...@usenet-verwaltung.de> wrote:
>> Weil der cast bei einem C89/C90 Compiler evt. einen fehlenden Prototyp
>> fuer malloc "verdeckt" (Default-Return-Typ ist dort "int") ...
>Irgendwie kann ich das Argument bald nicht mehr hoeren ... Wenn jemand seinen
>Compiler nicht so konfiguriert hat, dass er in diesem Falle warnt, dann hat
>dieser Jemand noch einen ganzen Sack anderer Probleme, und dann kommt's auf
>den Cast mehr oder weniger nicht an:-)
Witzigerweise hast Du da Recht - wenn man gecastete malloc()s sieht,
kann man ziemlich sicher sein, dass in dem Code noch ein ganzer Sack
von anderen Ungereimtheiten und Defekten zu finden sein wird. Dann
sollten die Casts zur leichteren Erstdiagnose besser 'drin bleiben.
b.
Juergen Ilse
Oliver S. <Foll...@gmx.net> wrote:
[ NULL als int-Wert 0 definiert ]
>> Du irrst. Das ist viel gebraeuchlicher als du vielleicht denkst,
> Das ist aber nur in C++ legal.
Du irrst. Der standard verlangt fuer das Macro NULL, dasses zu einer
"Null-Pointer-Konstante" erweitert wird. Der Integer-Wert 0 ist eine
solche (und zwar auch, wenn er kein Pointer ist). Aus diesem Grunde
ist in vielen Situationen (in allen, wo NULL nicht implizit auf den
passenden Typ gecastet wird) ein cast auf den passenden Typ notwendig,
auch dann, wenn man ein (void*)0 benoetigen sollte muss ggfs. nach
(void*) gecastet werden.
Rainer Weikusat
> Alexander Bartolich <alexander...@gmx.at> wrote:
>> begin Juergen Ilse:
>>> Bei dieser Zeile haette ich vermutlich ein "if (p == NULL)"
>>> geschrieben, aber ich weiss, dass das eher Geschmacksache ist ...
>> NULL considered harmful.
>
> In diesem Fall nicht. Hier benoetige ich eine "Nullpointerkonstante"
> und NULL ist garantiert eine solche
Nur, weil Du darauf bestehst, daß ein ungültiger Zeiger irgendwie doch
dasselbe sein müsse, wie ein gültiger Zeiger. Ein ungültiger Zeiger
ist aber lediglich ein Ding, das kein gültiger Zeiger ist, dh als
'Wahrheitswert' (was es in C auch eigentlich nicht gibt)
interpretiert, bedeutet er 'falsch'. Das sind zwei Fragen:
if (p) /* does p have a value */
und
if (!p) /* doesn't p have a value */
Ich weiß, modern wäre das wie folgt ausgedrückt
if ((NULL == p) != FALSE)
und man kann da bestimmt noch ein paar Klammern mehr drin
unterbringen, aber die haben all lediglich die Funktion, da ohne
Funktion herumzustehen und ob ihrer unerklärlichen Existenz bestaunt
zu werden. In C kann man sehr schnell sehr viel Code schreiben, weil
die Syntax sehr frugal ist, und Leute, die etwas mehr Wortgeklingel
gewohnt sind, haben gewisse Problem, sich an den Gedanken zu gewöhnen,
daß es so auch geht. Das ist ein menschliches Problem und mit dem
schönen Sprichtwort 'Was der Bauer nit kennt, daß er frißt nit' recht
gut umschrieben.
Andreas Burmester
>Juergen Ilse <jue...@usenet-verwaltung.de> writes:
>> Alexander Bartolich <alexander...@gmx.at> wrote:
>>> begin Juergen Ilse:
>>>> Bei dieser Zeile haette ich vermutlich ein "if (p == NULL)"
>>>> geschrieben, aber ich weiss, dass das eher Geschmacksache ist ...
>>> NULL considered harmful.
>>
>> In diesem Fall nicht. Hier benoetige ich eine "Nullpointerkonstante"
>> und NULL ist garantiert eine solche
>Nur, weil Du darauf bestehst, daß ein ungültiger Zeiger irgendwie doch
>dasselbe sein müsse, wie ein gültiger Zeiger.
Du vermischst hier mit Deinem (*) "ungueltigen Zeiger" zwei Sachen, von
denen eine garantiert nichts mit dem obigen Thema zu tun hat, und die
andere, aeh, eigentlich auch nicht.
Ungueltigkeiten von Zeigern kommen in C in 2 Inkarnationen daher:
- Als Repraesentationen, also Bitmustern, denen kein Zeigerwert
entspricht. Nennt man auch "Traprepraesentation". Das blosse
Erwaehnen eines Zeigerobjektes, das eine enthaelt, ist UB. Nur solche
Zeiger wuerde ich "ungueltig" nennen. Von denen ist oben offensicht-
lich nicht die Rede. Auch weil es keine Moeglichkeit gibt, ein Objekt
irgendwie daraufhin zu testen.
- Und als Zeigerwert, egal ob aus einem Zeigerobjekt gelesen oder direkt
hingeschrieben, der ungueltig ist, weil er nicht auf ein Objekt (oder
das 1. Element hinter einem Feld) oder eine Funktion weist. Mit dem
laesst sich trotzdem allerhand machen: Zuweisen, vergleichen mit
andern Zeigerwerten, testen auf 0, nur nicht dereferenzieren. Fuer
den Standard sind das woertlich "ungueltige Zeiger*werte*"; wenn sie
in einem Objekt stehen, ist das Objekt damit nicht ungueltig. Tests
auf gueltige Werte gibt es genauso wenig, wie zuvor. Mit der einen
bekannten Ausnahme...
> Ein ungültiger Zeiger
>ist aber lediglich ein Ding, das kein gültiger Zeiger ist, dh als
>'Wahrheitswert' (was es in C auch eigentlich nicht gibt)
>interpretiert, bedeutet er 'falsch'.
Ist mithin alles falsch: Du kannst nur von (un)gueltigen Zeigerwerten
reden, und denen ist kein testbarer "Wahrheitswert" eigen.
> Das sind zwei Fragen:
> if (p) /* does p have a value */
Falsch, denn `p' enthaelt in jedem Fall einen Wert, der ungueltig sein
kein, egal ob der Ausdruck `p' nun zu "wahr" evaluiert oder nicht.
Ist "Nullpointer" neuerdings ein Schimpfwort, dass Du es nicht
aussprechen magst?
>und
> if (!p) /* doesn't p have a value */
Gleiche Antwort.
>Ich weiß, modern wäre das wie folgt ausgedrückt
> if ((NULL == p) != FALSE)
Nicht alles, was unsinnig ist, ist modern.
>und man kann da bestimmt noch ein paar Klammern mehr drin
>unterbringen, aber die haben all lediglich die Funktion, da ohne
>Funktion herumzustehen und ob ihrer unerklärlichen Existenz bestaunt
>zu werden. In C kann man sehr schnell sehr viel Code schreiben, weil
>die Syntax sehr frugal ist, und Leute, die etwas mehr Wortgeklingel
>gewohnt sind, haben gewisse Problem, sich an den Gedanken zu gewöhnen,
>daß es so auch geht. Das ist ein menschliches Problem und mit dem
>schönen Sprichtwort 'Was der Bauer nit kennt, daß er frißt nit' recht
>gut umschrieben.
"Wortgekingel" - <sofort unterschreib'>.
(*) Der Begriff "(un)gueltiger Zeiger" wird in der Sprachbeschreibung
nirgends definiert. Er wird allerdings - ich halte das fuer einen
Defekt - genau 2mal benutzt, naemlich in 7.18.1.4. Gemeint ist dort
aber offensichtlich "valid pointer value".
b.
Rainer Weikusat
> Ungueltigkeiten von Zeigern kommen in C in 2 Inkarnationen daher:
>
> - Als Repraesentationen, also Bitmustern, denen kein Zeigerwert
> entspricht. Nennt man auch "Traprepraesentation". Das blosse
> Erwaehnen eines Zeigerobjektes, das eine enthaelt, ist UB. Nur solche
> Zeiger wuerde ich "ungueltig" nennen. Von denen ist oben offensicht-
> lich nicht die Rede.
Eine 'trap represenation' ist ein Ding, daß nach den Regeln der
Sprache nicht zustandekommen kann, es ist also müßig, sich hübsche
Namen dafür auszudenken.
> - Und als Zeigerwert, egal ob aus einem Zeigerobjekt gelesen oder direkt
> hingeschrieben, der ungueltig ist, weil er nicht auf ein Objekt (oder
> das 1. Element hinter einem Feld) oder eine Funktion weist. Mit dem
> laesst sich trotzdem allerhand machen: Zuweisen, vergleichen mit
> andern Zeigerwerten, testen auf 0, nur nicht dereferenzieren.
Und dann gibt es noch eine Repräsentation für 'Zeiger, der garantiert
nicht auf ein Objekt zeigt', die keine trap repräsentation ist und weil
man eine Zeigervariable, die diesen Wert hat, nie dereferenzieren
kann. Ich habe mir erlaubt, dafür das deutsche Wort 'ungültig' zu
verwenden, denn ein gültiger Zeiger ist für mich einer, den man
dereferenzieren kann.
>> Ein ungültiger Zeiger
>>ist aber lediglich ein Ding, das kein gültiger Zeiger ist, dh als
>>'Wahrheitswert' (was es in C auch eigentlich nicht gibt)
>>interpretiert, bedeutet er 'falsch'.
>
> Ist mithin alles falsch: Du kannst nur von (un)gueltigen Zeigerwerten
> reden, und denen ist kein testbarer "Wahrheitswert" eigen.
Wie oben demonstriert, kann ich von ungültigen Zeigern sprechen.
>> Das sind zwei Fragen:
>
>> if (p) /* does p have a value */
>
> Falsch, denn `p' enthaelt in jedem Fall einen Wert, der ungueltig sein
> kein, egal ob der Ausdruck `p' nun zu "wahr" evaluiert oder nicht.
>
> Ist "Nullpointer" neuerdings ein Schimpfwort, dass Du es nicht
> aussprechen magst?
Die 'Nullpointerkonstante' ist außer zu Initialisierungszwecken
redundant. Notwendigerweise kann sie keine trap representation sein,
die Du hier ohne ersichtlichen Grund in die Diskussion eingeführt
hast. Ich kann das aber nochmal auf Deutsch ausdrücken:
if (p) /* zeigt das auf ein Objekt */
if (!p) /* zeigt das nicht auf ein Objekt */
Korrekte Intitialisierung etc vorausgesetzt. Die Formulierung wird ein
keinster Weise dadurch besser, daß man eine pascal-artigere Syntax
verwendet:
if (p != NULL) /* warum negativ? */
if (p == NULL) /* warum positiv? */
Hier wird bloß wieder suggeriert, daß folgender Algoritmus eine Folge
von Nullen ausgeben wird:
char *p = NULL, *pp;
pp = &p
do {
printf("%d", *pp);
} while (p - ++pp < sizeof(char *));
was die Sprache aber nicht garantiert. Irgendjemand, der den Wert aber
unbedingt wissen möchte, schreibt sich also ein Programm, daß ihn
ausgibt und - hab ichs doch gleich gewußt -
char *p = NULL;
if ((int)p == 0)
Es ist einfacher, Leuten den Floh gar nicht erst ins Ohr zu setzten,
als ihnen den Gedanken hinterher wieder auszureden.
Rainer Weikusat
> Ungueltigkeiten von Zeigern kommen in C in 2 Inkarnationen daher:
>
> - Als Repraesentationen, also Bitmustern, denen kein Zeigerwert
> entspricht. Nennt man auch "Traprepraesentation". Das blosse
> Erwaehnen eines Zeigerobjektes, das eine enthaelt, ist UB. Nur solche
> Zeiger wuerde ich "ungueltig" nennen. Von denen ist oben offensicht-
> lich nicht die Rede.
Eine 'trap represenation' ist ein Ding, daß nach den Regeln der
Sprache nicht zustandekommen kann, es ist also müßig, sich hübsche
Namen dafür auszudenken.
> - Und als Zeigerwert, egal ob aus einem Zeigerobjekt gelesen oder direkt
> hingeschrieben, der ungueltig ist, weil er nicht auf ein Objekt (oder
> das 1. Element hinter einem Feld) oder eine Funktion weist. Mit dem
> laesst sich trotzdem allerhand machen: Zuweisen, vergleichen mit
> andern Zeigerwerten, testen auf 0, nur nicht dereferenzieren.
Und dann gibt es noch eine Repräsentation für 'Zeiger, der garantiert
nicht auf ein Objekt zeigt', die keine trap repräsentation ist und weil
man eine Zeigervariable, die diesen Wert hat, nie dereferenzieren
kann, habe ich mir erlaubt, dafür das deutsche Wort 'ungültig' zu
verwenden, denn ein gültiger Zeiger ist für mich einer, den man
dereferenzieren kann.
>> Ein ungültiger Zeiger
>>ist aber lediglich ein Ding, das kein gültiger Zeiger ist, dh als
>>'Wahrheitswert' (was es in C auch eigentlich nicht gibt)
>>interpretiert, bedeutet er 'falsch'.
>
> Ist mithin alles falsch: Du kannst nur von (un)gueltigen Zeigerwerten
> reden, und denen ist kein testbarer "Wahrheitswert" eigen.
Wie oben demonstriert, kann ich von ungültigen Zeigern sprechen.
>> Das sind zwei Fragen:
>
>> if (p) /* does p have a value */
>
> Falsch, denn `p' enthaelt in jedem Fall einen Wert, der ungueltig sein
> kein, egal ob der Ausdruck `p' nun zu "wahr" evaluiert oder nicht.
>
> Ist "Nullpointer" neuerdings ein Schimpfwort, dass Du es nicht
> aussprechen magst?
Die 'Nullpointerkonstante' ist außer zu Initialisierungszwecken
Horst Kraemer
<falk.h...@student.uni-tuebingen.de> wrote:
> Kein ernstzunehmenden Compiler definiert NULL auf 0.
Viele gcc-Implementierungen definieren
#define NULL 0
Dass Microsoft und Borland in C++
#define NULL 0
und in C
#define NULL 0 ((void*)0)
[
Borlands DOS-16 Bit-Compiler definieren feinsinnig
#define NULL 0L
sowohl in C als auch in C++
]
verwenden, hat nur Kompatibilitaets - sprich - Marketinggruende.
Bei diesen Compilern (und durch das trickreiche 0L auch bei Borlands
DOS-Compilern bei 32-Bit-Zeigern und 16-Bit-ints) ist sichergestellt,
dass bei einer vararg-Funktion, die als letzten Parameter einen
Nullzeiger erwartet, Aufrufe wie
f(bla,p1,p2,p3,NULL);
unabhaengig von der aktuellen Groesse eines Zeigers und eines ints
immer "funktionieren", wogegen fuer uneingeschraenkt portable
Programme
f(bla,p1,p2,p3,(void*)NULL);
erforderlich ist, da der Standard explizit *zulaesst*, dass NULL als
(int)0 definiert ist. MS und Borland koennen schlecht ploetzlich NULL
als 0 definieren, wenn sie es immer als (void*)0 definiert haben und
damit existierende Programme, die fuer *diese* Compiler geschrieben
wurden, moeglicherweise "brechen".
Sei ihm wie ihm wolle, ein C-Programm, das portabel sein moechte, muss
davon ausgehen, dass NULL sowohl 0 als auch als (void*)0 definiert
sein kann, da es bei Arten der Implementierung gibt - wenn es NULL
verwendet.
Ich persoenlich empfinde daher das Makro NULL als ausgesprochenen
Fremdkoerper in C. Es fuehrt eine Abstraktionskruecke ein, die nicht
eindeutig definiert ist - und dies streng genommen ein Unding.
MfG
Horst
Helmut Schellong
> Ich persoenlich empfinde daher das Makro NULL als ausgesprochenen
> Fremdkoerper in C. Es fuehrt eine Abstraktionskruecke ein, die nicht
> eindeutig definiert ist - und dies streng genommen ein Unding.
Sehe ich auch so.
Ich verwende seit ewig lieber
if (!p)
und ähnlich.
Das ist absolut eindeutig.
--
Mit freundlichen Grüßen
Helmut Schellong v...@schellong.biz
www.schellong.de www.schellong.com www.schellong.biz
http://www.schellong.de/c.htm