Mailinglist Archive: opensuse-programming-de (182 mails)

< Previous Next >
Re: GCC Warnung dereferencing type-punned pointer
  • From: Ralf Corsepius <corsepiu@xxxxxxxxxxxxxx>
  • Date: Mon, 15 Sep 2003 13:33:59 +0200
  • Message-id: <1063625639.1404.1534.camel@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
On Mon, 2003-09-15 at 07:40, Michael Matz wrote:
> Hi,
>
> On Mon, 15 Sep 2003, Ralf Corsepius wrote:
>
> > :) Warum meinst Du hatte ich gefragt?
> >
> > Jeder halbwegs portable Code eines gewissen Umfangs liefert irgendwo
> > Warnungen (z.B.: gcc).
>
> Falsch. Viele Warnungen mit GCC sind ein Hinweis auf
> _Nicht_-Portabilitaet.

Wohl wahr, doch eigentlich meinte ich meine Anmerkung anders:
Die GCC-Quellen selbst sind ein gutes Beispiel für Quellen eines
gewissen Umfangs, die sich nicht warnungsfrei übersetzen lassen und
einen Strom von Warnungen auslösen, in denen "ernsthafte Warnungen"
untergehen können..

Ich halte das für normal, da GCC selbst, wie praktisch jeder andere
C-Code auch, auch nur "halbwegs portabel" ist.

> Oder warte, eigentlich hast du recht. Wenn der
> Code nur halbwegs, nicht voellig, portabel ist, dann werden in der Tat
> einige Warnungen geworfen, naemlich gerade an den nicht portablen Stellen.
100% portablen Code habe ich noch nicht gesehen ;)

Es gibt immer irgendwo einen Compiler, eine Architektur, ein OS oder
eine Änderung im Standard, die "Warnungen" auslösen.

Klassische Beispiele hierfür wären die GNU-Toolchain, der Linux-Kernel
und die glibc2. Eigentlich jedes GCC-Release hat dort irgendwo irgendwas
zerbrochen oder hatte irgendwas am Code zu bemängeln gehabt, obwohl der
Code von 100en von Leuten gesichtet und von noch mehr Leuten benutzt
werden.

> > Ich spreche davon, dass ich die ISO/ANSI C-Sprachdefinition für zu
> > schwach halte und die GCC-Entwickler lieber "Anwender-Erwartung" opfern,
> > um die Grenzen des laut _ihrer_ Interpretation des Standards Erlaubten
> > auszunutzen.
>
> Dann verlass dich halt nicht auf das, was der GCC interpretiert, sondern
> eben nur auf den Standard. Das ist ein valider Standpunkt, und wird dich
> vor jedem Interpretationsspielraum schuetzen. Einfach keine im Standard
> undefinierten oder implementation defined Dinge tun.
Das Problem besteht darin sie zu erkennen.

> Indem er von Anfang an nicht non-C geschrieben haette, ganz einfach.
> Das ist eben das Problem, die Masse von C-Programmierern weiss einfach
> nichts ueber die Sprache, in der sie ihre Programme schreiben. Nur
> kann man dabei in der Compilerentwicklung nur sehr begrenzt Ruecksicht
> nehmen. Der Grund ist der, dass man von N Leuten, die die Sprache
> nicht im Detail kennen, N verschiedene Meinungen bekommt, wie sich
> bestimmte Konstrukte verhalten muessten. Die einzige Chance die man
> hat ist, sich an einen Standard zu halten.
Deine Argumentation hat was vom "Hitchhiker" (Die Pläne zum Ausbau der
Umgehungsstrasse lagen öffentlich aus) ;-)

Ralf



< Previous Next >
References