Neuer Wurm?
Thomas Trautmann
ich hab mal wieder in meiner Apache-Logfile nachgeschaut, und folgendes
entdeckt:
80.134.106.19 - - [06/May/2002:16:41:37 +0200] "HEAD /cgi-bin/ikonboard/
HTTP/1.0" 404 0
80.134.106.19 - - [06/May/2002:16:41:39 +0200] "HEAD /foldoc/ HTTP/1.0" 404
0
80.134.106.19 - - [06/May/2002:16:41:41 +0200] "HEAD /cgi-bin/adcycle/
HTTP/1.0" 404 0
80.134.106.19 - - [06/May/2002:16:41:43 +0200] "GET
/cgi-bin/store.cgi?StartID=../etc/passwd%00.html HTTP/1.0" 404 287
80.134.106.19 - - [06/May/2002:16:41:44 +0200] "HEAD /cgi-bin/bbs_forum.cgi
HTTP/1.0" 404 0
80.134.106.19 - - [06/May/2002:16:41:45 +0200] "HEAD
/cgi-bin/commerce.cgi?page=../../../../etc/hosts%00index.html HTTP/1.0" 404
0
80.134.106.19 - - [06/May/2002:16:41:47 +0200] "GET
/cgi-bin/auktion.pl?menue=../../../../../../../../../../../../../etc/passwd
HTTP/1.0" 404 288
80.134.106.19 - - [06/May/2002:16:41:49 +0200] "GET
/cgi-bin/hsx.cgi?show=../../../../../../etc/passwd%00 HTTP/1.0" 404 285
Das zieht sich noch über weitere 30 Zeilen durch und ging über 2 Minuten so.
Das komische ist, das sich glaub ich kaum ein Befehl wiederholt.
Es ist auch der zugriff auf HEAD sichtbar was eigentlich auch Neu ist. Und
zu guter Letzt: Das ging bis jetzt nur von der obigen IP aus. Es sind also
keine weiteren Einträge verzeichnet.
Google spuckt auch was aus:
http://lists.suse.com/archive/suse-security/2001-Nov/0310.html
Glaub mit dem neuesten Apache 1.3* brauch ich mir da keine gedanken zu
machen.
MfG
Thomas Trautmann
Joerg Luttmer
Thomas Trautmann <Rayma...@gmx.net> schrieb:
>ich hab mal wieder in meiner Apache-Logfile nachgeschaut, und folgendes
>entdeckt:
[Apache-Log Files mit HTTP-Abfragen]
>Das zieht sich noch über weitere 30 Zeilen durch und ging über 2 Minuten
>so.
Es waere interessant zu sehen, was in dem Betriebssystem-Log zu finden
ist. So wie es aussieht, scheint es eher allgemeiner Vulnerability
Scanner wie Nessus (www.nessus.org) zu sein, der dort automatisiert
Abfragen startet.
>Das komische ist, das sich glaub ich kaum ein Befehl wiederholt.
Das waere unproduktiv :-)
>Google spuckt auch was aus:
>http://lists.suse.com/archive/suse-security/2001-Nov/0310.html
Dort gehen sie wegen des dortigen Log von whisker aus
http://lists.suse.com/archive/suse-security/2001-Nov/0314.html:
| Seems to be nice scan output like produced by rain forest puppys cgi uln
| scanner.
Weitere Infos kannst Du hier dazu finden:
http://www.wiretrip.net/rfp/p/doc.asp?id=21&iface=2
Da aber nach der /etc/passwd gefragt wird, glaube ich nicht, dass es
sich um den cgi-Scanner handelt.
>Glaub mit dem neuesten Apache 1.3* brauch ich mir da keine gedanken zu
>machen.
Einstellungssache... Die Version allein berechtigt nicht zu dieser
Annahme.
Viele Gruesse,
/Joerg
--
Joerg Luttmer
" . " @atosorigin.com
0xEC8638D3 GnuPG
Thomas Trautmann
"Joerg Luttmer" <Y2Kd...@atosorigin.com> schrieb im Newsbeitrag
news:he4idush1est9qf6r...@4ax.com...
> Moin,
>
> Thomas Trautmann <Rayma...@gmx.net> schrieb:
>
> >ich hab mal wieder in meiner Apache-Logfile nachgeschaut, und folgendes
> >entdeckt:
> [Apache-Log Files mit HTTP-Abfragen]
> >Das zieht sich noch über weitere 30 Zeilen durch und ging über 2 Minuten
> >so.
>
> Es waere interessant zu sehen, was in dem Betriebssystem-Log zu finden
> ist. So wie es aussieht, scheint es eher allgemeiner Vulnerability
> Scanner wie Nessus (www.nessus.org) zu sein, der dort automatisiert
> Abfragen startet.
Hmm, setzt nessus nicht eine Installation vorraus? Hab nämlich nichts
dergleichen bei mir installiert.
> >Das komische ist, das sich glaub ich kaum ein Befehl wiederholt.
>
> Das waere unproduktiv :-)
Kenn das nur von Nimda, 10 mal den gleichen Befehl abfragen und dann neue
IP. Deshalb bin ich auch davon ausgegangen, das es sich um einen neuen Wurm
handelt
> >Google spuckt auch was aus:
> >http://lists.suse.com/archive/suse-security/2001-Nov/0310.html
>
> Dort gehen sie wegen des dortigen Log von whisker aus
>
> http://lists.suse.com/archive/suse-security/2001-Nov/0314.html:
>
> | Seems to be nice scan output like produced by rain forest puppys cgi
uln
> | scanner.
>
> Weitere Infos kannst Du hier dazu finden:
> http://www.wiretrip.net/rfp/p/doc.asp?id=21&iface=2
Werd ich mir später mal angucken.
> Da aber nach der /etc/passwd gefragt wird, glaube ich nicht, dass es
> sich um den cgi-Scanner handelt.
>
> >Glaub mit dem neuesten Apache 1.3* brauch ich mir da keine gedanken zu
> >machen.
>
> Einstellungssache... Die Version allein berechtigt nicht zu dieser
> Annahme.
Bin aber sicherer als mit einem IIS dran :-)
Danke für die Infos
MfG
Thomas Trautmann
Bjoern Wunschik
>"Joerg Luttmer" <Y2Kd...@atosorigin.com> schrieb:
>> Es waere interessant zu sehen, was in dem Betriebssystem-Log zu finden
>> ist. So wie es aussieht, scheint es eher allgemeiner Vulnerability
>> Scanner wie Nessus (www.nessus.org) zu sein, der dort automatisiert
>> Abfragen startet.
>
>Hmm, setzt nessus nicht eine Installation vorraus? Hab nämlich nichts
>dergleichen bei mir installiert.
Die Anfragen kamen doch von außen, oder? Dann brauchst Du als "Opfer"
natürlich nichts zu installieren.
mfg
Björn Wunschik
Joerg Luttmer
Thomas Trautmann <Rayma...@gmx.net> schrieb:
>Hmm, setzt nessus nicht eine Installation vorraus? Hab nämlich nichts
>dergleichen bei mir installiert.
Nessus setzt keine Installation bei Dir voraus. Nur der Anwender muss
bei sich einen Client und einen (Nessus-)Server im Zugriff haben. Der
Server uebernimmt dann den Scan.
Unter http://www.nessus.org ist dies sehr gut erklaert.
Es kann natuerlich auch Retina, ISS... sein.
>> >Glaub mit dem neuesten Apache 1.3* brauch ich mir da keine gedanken
>zu
>> >machen.
>>
>> Einstellungssache... Die Version allein berechtigt nicht zu dieser
>> Annahme.
>
>Bin aber sicherer als mit einem IIS dran :-)
Kann man so nie sagen. Wie Du schon beim SuSE-Link feststellen
konntest, gibt es auch CGI-Scanner, was natuerlich bedeutet, dass es
dort auch Probleme geben kann. Die Sicherheit eines Programmes ist nur
eine Seite des Problems, die Einstellungen eine ganz andere. Ein IIS
kann auch sehr sicher sein.
Versuche doch einmal Nessus bei Dir zu installieren und den Server von
aussen zu testen.
Viele Gruesse,
/Joerg
P.S. Achtung: Die Verwendung von Nessus gegen andere Server, die einem
nicht gehoeren, kann strafbar sein!
Daniel Mewes
> Kann man so nie sagen. Wie Du schon beim SuSE-Link feststellen
> konntest, gibt es auch CGI-Scanner, was natuerlich bedeutet, dass es
> dort auch Probleme geben kann. Die Sicherheit eines Programmes ist nur
> eine Seite des Problems, die Einstellungen eine ganz andere. Ein IIS
> kann auch sehr sicher sein.
Ein System kann aber immer nur so sicher sein wie das Programm. Falsche
Einstellungen können die Sicherheit nur noch weiter herabsetzten.
MfG
Daniel Mewes
--
Daniel Mewes
Skyper: 5774213 oder per E-Mail (weiterleitung) danie...@gmx.de
E-Mail: danie...@onlinehome.de
http://www.ilus-ki.de
Bjoern Wunschik
>P.S. Achtung: Die Verwendung von Nessus gegen andere Server, die einem
>nicht gehoeren, kann strafbar sein!
Wieso?
AFAIK werden durch nessus weder Daten ausspioniert noch verändert. Es
wird lediglich das Zielsystem auf sein Verhalten geprüft.
mfg
Björn Wunschik
Joerg Luttmer
Man kann aber auch schoen NT/2K-Server abschiessen ;->
(O.K. um Fair zu bleiben: letzten habe ich auch einen telnetd unter
Solaris abgeschossen; weiterhin reagieren auch einige Cluster
alergisch gegenüber nmap u.s.w.)
Insofern gehe ich davon aus - so war es auch gemeint - dass man
eventuell Aerger bekommen kann. Und wenn man nmap/nessus nicht kennt,
dann ist dies sogar eher wahrscheinlich.
Viele Gruesse,
/Joerg
Johannes Lichtenberger
> Kann man so nie sagen. Wie Du schon beim SuSE-Link feststellen
> konntest, gibt es auch CGI-Scanner, was natuerlich bedeutet, dass es
> dort auch Probleme geben kann. Die Sicherheit eines Programmes ist nur
> eine Seite des Problems, die Einstellungen eine ganz andere. Ein IIS
> kann auch sehr sicher sein.
Ein IIS kann nicht sicher sein. Das Programm ansich ist ein einziger Bug
und kann auch nicht durch irgendwelche obskuren Einstellungen repariert
werden.
Gruss, Johannes
Rainer Weikusat
Das Problem liegt tiefer: Wenn es bei M$-Software einen wirklich
ärgerlichen Fehler gibt, wird jemand drangesetzt, der Code schreibt,
um diesen speziellen Sonderfall 'auf dem Weg' abzufangen¹ (deswegen
sind die Dinger auch so fett) und das Verfahren ist natürlich völliger
Unfug, nur geht das schneller und vor allem besser mit gering
qualfizierten Arbeitskräften (dh zB solchen mit wenig bis keinen
praktischen Kenntnissen).
Dasselbe Baumuster zieht sich durchgängig durch alle M$-'Konzepte',
angefangen von dem Zertifizierungs-Unsinn bis hin zum 'end
user'-support und es lautet vermutlich 'Geht schon irgendwie, falls
man um die Benutzerfehler herumwürgt'. Leider ist das ein Irrtum: Es
handelt sich um Programmfehler, => robustness principle.
1) Nachweislich war das für den index-dll-exploit so, bei OE sieht es
stark danach aus und ich behaupte die Verallgemeinerung einfach
mal.
Stefan Weimar
>Ein IIS kann nicht sicher sein. Das Programm ansich ist ein einziger Bug
>und kann auch nicht durch irgendwelche obskuren Einstellungen repariert
>werden.
Wenn man ihn beendet, ist er so sicher wie ein Server ohne
Netzwerkkabel. Allerdings verhält sich der Nutzen genau umgekehrt...
SCNR
Stefan
--
Stefan Weimar
<joh...@warlock.toppoint.de>
Joerg Luttmer
Johannes Lichtenberger <joha...@visualgrafyx.com> wrote:
>> eine Seite des Problems, die Einstellungen eine ganz andere. Ein IIS
>> kann auch sehr sicher sein.
>
>Ein IIS kann nicht sicher sein. Das Programm ansich ist ein einziger Bug
>und kann auch nicht durch irgendwelche obskuren Einstellungen repariert
>werden.
Naja, so pauschal wuerde ich das nicht sagen. (Wobei ich weit davon
entfernt bin, meine Hand fuer die Sicherheit des IIS ins Feuer zu
legen :-)
Der IIS ist auch nur eine Stueck Software, deren Fehler kurz nach dem
Herauskommen gefunden werden muessen. (Meines Wissens wurden noch
nicht alle IIS verunstaltet/verschoenert).
Zum anderen ist naetuerlich der Begriff "sicher" relativ und das
hoffte ich mit dem noch schwammigerem "kann auch sehr sicher" deutlich
gemacht zu haben. ("sicher" gegen ueber wem und fuer was?).
Viele Gruesse,
/Joerg
Felix von Leitner
> >Ein IIS kann nicht sicher sein. Das Programm ansich ist ein einziger Bug
> >und kann auch nicht durch irgendwelche obskuren Einstellungen repariert
> >werden.
> Naja, so pauschal wuerde ich das nicht sagen.
Gut, daß dich keiner gefragt hat.
> (Wobei ich weit davon entfernt bin, meine Hand fuer die Sicherheit des
> IIS ins Feuer zu legen :-)
Was postest du also hier rum, wenn du dich zu keiner Aussage durchringen
kannst?
> Der IIS ist auch nur eine Stueck Software,
Welch bahnbrechende Erkenntnis! Was kommt morgen? Daß IIS aus Nullen
und Einsen besteht? "stating the obvious"...
> deren Fehler kurz nach dem Herauskommen gefunden werden muessen.
Du wirst lachen, es gibt auch Software, bei denen überhaupt nie Fehler
gefunden werden.
--
Wie wäre es, wenn Du Dir erst einmal einen Minimalclue zulegst, bevor Du
hier geistige Dünnsäure verklappst?
--Robin Socha in <iloverobin.8...@news.socha.net>
Chris Haaser
>> Der IIS ist auch nur eine Stueck Software,
>> deren Fehler kurz nach dem Herauskommen gefunden werden muessen.
>
> Du wirst lachen, es gibt auch Software, bei denen überhaupt nie Fehler
> gefunden werden.
Was nix heißen muss.
--
Support: "Starten Sie das Programm mal. Was steht auf Ihrem Monitor?"
DAU: "Ein Bild von meiner Frau."
Michael Bergbauer
> Du wirst lachen, es gibt auch Software, bei denen überhaupt nie Fehler
> gefunden werden.
"Hello World"? SCNR
Kannst du mir abgesehen davon ein Stueck Software zeigen, bei dem
nach der ersten Veroeffentlichung mit neuen Features keine Fehler
gefunden wurden? Wuerd mich wirklich interessieren, ob es sowas
gibt, und wenn ja, in welchem Umfeld
--
Michael Bergbauer <mic...@noname.franken.de>
use your idle CPU cycles - See http://www.distributed.net for details.
Visit our mud Geas at geas.franken.de Port 3333
Harald Laabs
> Felix von Leitner <usenet-...@fefe.de> writes:
>
>> Du wirst lachen, es gibt auch Software, bei denen überhaupt nie Fehler
>> gefunden werden.
>
> "Hello World"? SCNR
>
> Kannst du mir abgesehen davon ein Stueck Software zeigen, bei dem
> nach der ersten Veroeffentlichung mit neuen Features keine Fehler
> gefunden wurden? Wuerd mich wirklich interessieren, ob es sowas
> gibt, und wenn ja, in welchem Umfeld
Soweit ich weiss hat bisher niemand den Preis fuer das auffinden eines
Fehlers in QMail beansprucht. Auch wenn man sonst geteilter Meinung zu
DJBs Software sein kann. (Ich setze sie nicht mehr ein.)
Harald
--
Mir ist es eigentlich egal, was ihr alles als Angriff bezeichnet, ich will
einfach eine Statistik!
-- Christoph Haene zum Thema "Statistik über Angriffe im Internet"
Matthias Stübner
Hallo Felix,
>> deren Fehler kurz nach dem Herauskommen gefunden werden muessen.
> Du wirst lachen, es gibt auch Software, bei denen überhaupt nie
> Fehler gefunden werden.
Du hast Recht: Ich lache. Es gibt davon genau EINE Software:
ungeschriebene. Ansonsten liste sie bitte auf.
(Aber es kommt bestimmt nur Dein übliches "löschen" und "so'n Scheiss"
Geseiere.)
--
Grußlos Matthias
Thomas Koenig
>Du wirst lachen, es gibt auch Software, bei denen überhaupt nie Fehler
>gefunden werden.
Und dann gab es noch das Programm, was gar nichts tun sollte,
und in dem ham se zwei Fehler gefunden:
*Fanfare* IEFBR14
Immo 'FaUl' Wehrenberg
> Soweit ich weiss hat bisher niemand den Preis fuer das auffinden eines
> Fehlers in QMail beansprucht.
Und djbdns? Oder Publicfile? Oder sonstige DJB-Software?
FaUl
end
This article does not support incompatible and broken newsreaders.
--
"The PROPER way to handle HTML postings is to cancel the article,
then hire a hitman to kill the poster, his wife and kids, and fuck
his dog and smash his computer into little bits.
Anything more is just extremism." - Paul Tomblin
Joerg Luttmer
Felix von Leitner <usenet-...@fefe.de> wrote:
[...]
(keine inhaltliche Aussagen zum Thema)
>Du wirst lachen,
Hahaha... Getan, und nun???
>... es gibt auch Software...
..war mir noch nicht bekannt.
Doch nun im Ernst:
Zitate von Teilsaetzen sollte nur Denunzianten und schlechten
Journalisten vorbehalten sein.
Ansonsten: http://www.kirchwitz.de/~amk/dni/netiquette - lohnt sich zu
lesen!
Nun zum Thema:
>Du wirst lachen, es gibt auch Software, bei denen überhaupt nie Fehler
>gefunden werden.
*Prust*
Selbst einem mittelmaessigem Informatikstudent ist bekannt, dass die
Fehlerlosigkeit von Software - erst recht von solcher im Umfang von
Apache, IIS etc. - bisher noch nicht bewiesen werden konnte.
Sollte sich natuerlich etwas geaendert haben, lasse ich mich gern
eines besseren belehren. Doch solange ich den Beweis nicht kenne
(Nein, keine unwissenschaftlichen Programmnamen), gehe ich davon aus,
dass der vom Vorredner weggelassene zweite Teil des Satze richtig ist,
auch wenn es sich um das "Hass-Produkt" Microsoft IIS handelt.
Viele Gruesse,
/Joerg
--
"Wer pauschalisiert hat immer unrecht."
(unbekannt)
Andreas Krennmair
> >Du wirst lachen, es gibt auch Software, bei denen überhaupt nie Fehler
> >gefunden werden.
>
> *Prust*
>
> Selbst einem mittelmaessigem Informatikstudent ist bekannt, dass die
> Fehlerlosigkeit von Software - erst recht von solcher im Umfang von
> Apache, IIS etc. - bisher noch nicht bewiesen werden konnte.
Lesen lernen! "Noch nie Fehler gefunden" != "Bewiesen, dass Programm
fehlerlos ist"
ak
Joerg Luttmer
Andreas Krennmair <use...@synflood.at> wrote:
>* Joerg Luttmer <J_Lu...@hamburg.de> [de.comp.security.misc]:
>> >Du wirst lachen, es gibt auch Software, bei denen überhaupt nie Fehler
>> >gefunden werden.
[...]
>> Selbst einem mittelmaessigem Informatikstudent ist bekannt, dass die
>> Fehlerlosigkeit von Software - erst recht von solcher im Umfang von
>> Apache, IIS etc. - bisher noch nicht bewiesen werden konnte.
>
>Lesen lernen! "Noch nie Fehler gefunden" != "Bewiesen, dass Programm
>fehlerlos ist"
Dies ist richtig. Doch es hiess "bei denen ueberhaupt nie Fehler
gefunden //werden//". Dies muss dann bewiesen werden...
Doch gehe ich davon aus, dass Deine Aussage die gemeinte war.
Also muss ich aber zugeben, dass ich den oben genannten Zusammenhang
ueberlesen haben :)
Viele Gruesse,
/Joerg
Juergen P. Meier
>
> *Prust*
>
> Selbst einem mittelmaessigem Informatikstudent ist bekannt, dass die
> Fehlerlosigkeit von Software - erst recht von solcher im Umfang von
> Apache, IIS etc. - bisher noch nicht bewiesen werden konnte.
Du Irrst.
> Sollte sich natuerlich etwas geaendert haben, lasse ich mich gern
> eines besseren belehren. Doch solange ich den Beweis nicht kenne
> (Nein, keine unwissenschaftlichen Programmnamen), gehe ich davon aus,
> dass der vom Vorredner weggelassene zweite Teil des Satze richtig ist,
> auch wenn es sich um das "Hass-Produkt" Microsoft IIS handelt.
Es gibt eine ganze Branche, die sich mit Funktionsbeweisen bei
Algorithmen und Software auseinandersetzt. Nein, das hat alles nicht
im entferntesten irgend ettwas mit Microsoft oder Windows zu tun.
Und auf einer ordentlichen Hochschule sollte man von sowas eigentlich
schon mal was gehoert haben - insbesondere in einem Informatikstudium.
Juergen
--
J...@lrz.fh-muenchen.de - "This World is about to be Destroyed!"
begin 0 outlooksucks.exe
If your Newsreader thinks this is an attachment then its broken.
end
Joerg Luttmer
"Juergen P. Meier" <J...@lrz.fh-muenchen.de> wrote:
>Joerg Luttmer <J_Lu...@hamburg.de> wrote:
>>
>Du Irrst.
>
>Es gibt eine ganze Branche, die sich mit Funktionsbeweisen bei
>Algorithmen und Software auseinandersetzt. Nein, das hat alles nicht
>im entferntesten irgend ettwas mit Microsoft oder Windows zu tun.
O.K. Wenn es sich hierbei auch um ganze Softwareprodukte handelt,
scheine ich schlecht informiert zu sein.
Dann bitte ich im weiteren mein Posting nicht mehr zu beachten. (Und -
sollte sich Herr von Leitner angegriffen gefuehlt haben - bitte Ihn um
Entschuldigung.
fu2p
Viele Gruesse,
/Joerg
Felix von Leitner
> ..war mir noch nicht bekannt.
Bisher sahst du nur wie ein kleiner inkompetenter Depp aus, jetzt siehst
du wie ein kleiner inkompetenter lernresistenter Troll aus.
*plonk*
Maik Hentsche
> Joerg Luttmer <J_Lu...@hamburg.de> wrote:
>>
>> *Prust*
>>
>> Selbst einem mittelmaessigem Informatikstudent ist bekannt, dass die
>> Fehlerlosigkeit von Software [..] bisher noch nicht bewiesen werden konnte.
>
> Du Irrst.
Du kennst eine Lösung für das Halteproblem? Die würde mich ja mal
interessieren, kannst du mal genauer werden?
so long
Maik
--
Immer wenn man glaubt ein idiotensicheres Programm herausgebracht zu
haben, wird der reichhaltige Genpool der Natur garantiert innerhalb
kuerzester Zeit einen besseren Idioten hervorbringen ... ;-)
[Juergen Ilse in de.comp.lang.c]
Felix Schlesinger
> "Juergen P. Meier" <J...@lrz.fh-muenchen.de> wrote:
>
>> Joerg Luttmer <J_Lu...@hamburg.de> wrote:
>>>
>>> *Prust*
>>>
>>> Selbst einem mittelmaessigem Informatikstudent ist bekannt, dass die
>>> Fehlerlosigkeit von Software [..] bisher noch nicht bewiesen werden konnte.
>>
>> Du Irrst.
>
> Du kennst eine Lösung für das Halteproblem? Die würde mich ja mal
> interessieren, kannst du mal genauer werden?
Man kann für einige Programme zeigen, das sie halten werden. Dies ist
ein Teil eines Korrektheitsbeweises. Wo ist das Problem?
Ciao
Felix
Rainer Weikusat
> >>> Selbst einem mittelmaessigem Informatikstudent ist bekannt, dass die
> >>> Fehlerlosigkeit von Software [..] bisher noch nicht bewiesen werden konnte.
> >>
> >> Du Irrst.
> >
> > Du kennst eine Lösung für das Halteproblem? Die würde mich ja mal
> > interessieren, kannst du mal genauer werden?
>
> Man kann für einige Programme zeigen, das sie halten werden. Dies ist
> ein Teil eines Korrektheitsbeweises. Wo ist das Problem?
Wer beweist wie die Korrektheit des Korrektheitsbeweises so, das es
nicht mehr darauf hinausläuft, das 'bestimmte Personengruppen' per se
glaubwürdig sind, und andere nicht.
Das wird aber in diesem Universum nicht mehr passieren.
Felix Schlesinger
> fam_Sch...@t-online.de (Felix Schlesinger) writes:
>> > Du kennst eine Lösung für das Halteproblem? Die würde mich ja mal
>> > interessieren, kannst du mal genauer werden?
>>
>> Man kann für einige Programme zeigen, das sie halten werden. Dies ist
>> ein Teil eines Korrektheitsbeweises. Wo ist das Problem?
>
> Wer beweist wie die Korrektheit des Korrektheitsbeweises so, das es
> nicht mehr darauf hinausläuft, das 'bestimmte Personengruppen' per se
> glaubwürdig sind, und andere nicht.
Niemand, deswegen ist es ja ein Beweiss. Dessen Korrektheit muss man
nicht beweisen.
> Das wird aber in diesem Universum nicht mehr passieren.
Es passiert schon die ganze Zeit.
Ciao
Felix
Jens Grivolla
> fam_Sch...@t-online.de (Felix Schlesinger) writes:
> > > Du kennst eine Lösung für das Halteproblem? Die würde mich ja mal
> > > interessieren, kannst du mal genauer werden?
> >
> > Man kann für einige Programme zeigen, das sie halten werden. Dies ist
> > ein Teil eines Korrektheitsbeweises. Wo ist das Problem?
>
> Wer beweist wie die Korrektheit des Korrektheitsbeweises so, das es
> nicht mehr darauf hinausläuft, das 'bestimmte Personengruppen' per se
> glaubwürdig sind, und andere nicht.
Das ist ein Problem, hat aber nichts mit dem Halteproblem zu tun.
Sinn von Korrektheitsbeweisen ist, dass man rein auf der Ebene von
syntaktischen Umformungen arbeitet, durch Anwendung von machinell
prüfbaren Regeln. D.h., dass man ab dem Moment, wo man sich auf die
Sinnhaftigkeit dieser Regeln geeinigt hat, über ein allgemeines
Verfahren verfügt, das für viele Situationen anwendbar ist.
Was dann die Aussagekraft eines solchen Beweises ist, ist ein weiteres
Problem und hängt von den vereinbarten Regeln ab.
Ciao,
Jens
Rainer Weikusat
> > Wer beweist wie die Korrektheit des Korrektheitsbeweises so, das es
> > nicht mehr darauf hinausläuft, das 'bestimmte Personengruppen' per se
> > glaubwürdig sind, und andere nicht.
>
> Niemand, deswegen ist es ja ein Beweiss. Dessen Korrektheit muss man
> nicht beweisen.
Denn sie ist allen 'wichtigen Leuten' self evident. Tun wir für den
Moment mal so, als wären 'die wichtigen Leute' nicht wichtig: Welchen
zwingenden Grund habe ich, den Menschen, der mir 'beweist', das die
Leute, die mein Programm geschrieben haben, keine Fehler gemacht
haben, mehr zu glauben, als denen?
> > Das wird aber in diesem Universum nicht mehr passieren.
>
> Es passiert schon die ganze Zeit.
Dann sollte sich eine Quelle dafür finden lassen. Wo bite?
Rainer Weikusat
> Rainer Weikusat <weik...@students.uni-mainz.de> writes:
> > > Man kann für einige Programme zeigen, das sie halten werden. Dies ist
> > > ein Teil eines Korrektheitsbeweises. Wo ist das Problem?
> >
> > Wer beweist wie die Korrektheit des Korrektheitsbeweises so, das es
> > nicht mehr darauf hinausläuft, das 'bestimmte Personengruppen' per se
> > glaubwürdig sind, und andere nicht.
>
> Das ist ein Problem, hat aber nichts mit dem Halteproblem zu tun.
Doch.
> Sinn von Korrektheitsbeweisen ist, dass man rein auf der Ebene von
> syntaktischen Umformungen arbeitet, durch Anwendung von machinell
> prüfbaren Regeln.
Ergo: Bevor Du jemanden überzeugen kannst, das 'der Korrektheitsbeweis'
zwangsläufig fehlerfrei ist, muß Du 'das Halteproblem' erst mal gelöst
haben.
> D.h., dass man ab dem Moment, wo man sich auf die
> Sinnhaftigkeit dieser Regeln geeinigt hat, über ein allgemeines
> Verfahren verfügt, das für viele Situationen anwendbar ist.
... um mir von jemandem, der auch nicht programmieren kann, versichern
zu lassen, das Programm wäre schon in Ordnung, dem man 'halt glaubt'.
Bitte mach mir mal einen 'Korrektheitsbeweis' für ein beliebiges Stück
Code, dessen 'Korrektheit' a priori 'ersichtlicher' ist, als die des
Originals. Ohne weitere Spezialkenntnisse.
Any references welcome.
Jens Grivolla
> Jens Grivolla <j-news...@grivolla.de> writes:
> > Rainer Weikusat <weik...@students.uni-mainz.de> writes:
> > Sinn von Korrektheitsbeweisen ist, dass man rein auf der Ebene von
> > syntaktischen Umformungen arbeitet, durch Anwendung von machinell
> > prüfbaren Regeln.
>
> Ergo: Bevor Du jemanden überzeugen kannst, das 'der Korrektheitsbeweis'
> zwangsläufig fehlerfrei ist, muß Du 'das Halteproblem' erst mal gelöst
> haben.
Wenn du einen automatischen Beweis für jedes mögliche Programm mit
jeder möglichen Eingabe willst. Das ist aber nicht gefordert.
> > D.h., dass man ab dem Moment, wo man sich auf die
> > Sinnhaftigkeit dieser Regeln geeinigt hat, über ein allgemeines
> > Verfahren verfügt, das für viele Situationen anwendbar ist.
>
> ... um mir von jemandem, der auch nicht programmieren kann, versichern
> zu lassen, das Programm wäre schon in Ordnung, dem man 'halt glaubt'.
Es geht nicht zwingend um ein Beweis-Programm. Ob die korrekte
Anwendung der Regeln von einem Menschen oder einer beliebigen Maschine
oder sonstwie geprüft wird, ist irrelevant.
Die Überprüfung einzelner syntaktischer Umformungen ist trivial im
Vergleich zur semantischen Prüfung eines Programmes.
> Bitte mach mir mal einen 'Korrektheitsbeweis' für ein beliebiges Stück
> Code, dessen 'Korrektheit' a priori 'ersichtlicher' ist, als die des
> Originals. Ohne weitere Spezialkenntnisse.
Gib mir eine Sprachdefinition, die von dir anerkannte Liste der
zulässigen Folgerungs-Regeln, dann kann ich von einer in der Sprache
der Regeln ausgedrückten Vor- auf eine korrekte Nachbedingung
schließen.
Diesen Beweis kann jeder Depp nachvollziehen, indem er einfach jeden
einzelnen Beweisschritt gegen die Regeln abgleicht.
> Any references welcome.
Lies ein beliebiges Skript zu einem entsprechenden Universitäts-Kurs.
Ciao,
Jens
Rainer Weikusat
> > > D.h., dass man ab dem Moment, wo man sich auf die
> > > Sinnhaftigkeit dieser Regeln geeinigt hat, über ein allgemeines
> > > Verfahren verfügt, das für viele Situationen anwendbar ist.
> >
> > ... um mir von jemandem, der auch nicht programmieren kann, versichern
> > zu lassen, das Programm wäre schon in Ordnung, dem man 'halt glaubt'.
>
> Es geht nicht zwingend um ein Beweis-Programm. Ob die korrekte
> Anwendung der Regeln von einem Menschen oder einer beliebigen Maschine
> oder sonstwie geprüft wird, ist irrelevant.
'Chicken & Egg'.
> Die Überprüfung einzelner syntaktischer Umformungen ist trivial im
> Vergleich zur semantischen Prüfung eines Programmes.
Was bitte heißt 'Überprüfung' in diesem Zusammenhang?
> > Bitte mach mir mal einen 'Korrektheitsbeweis' für ein beliebiges Stück
> > Code, dessen 'Korrektheit' a priori 'ersichtlicher' ist, als die des
> > Originals. Ohne weitere Spezialkenntnisse.
>
> Gib mir eine Sprachdefinition, die von dir anerkannte Liste der
> zulässigen Folgerungs-Regeln, dann kann ich von einer in der Sprache
> der Regeln ausgedrückten Vor- auf eine korrekte Nachbedingung
> schließen.
>
> Diesen Beweis kann jeder Depp nachvollziehen, indem er einfach jeden
> einzelnen Beweisschritt gegen die Regeln abgleicht.
IaW: Die zur Darstellung verwendete Sprache lernt.
> > Any references welcome.
>
> Lies ein beliebiges Skript zu einem entsprechenden
> Universitäts-Kurs.
Leider verloren. Ich hatte das Mißvergnügen.
Rudolf Polzer
> fam_Sch...@t-online.de (Felix Schlesinger) writes:
> > > Wer beweist wie die Korrektheit des Korrektheitsbeweises so, das es
> > > nicht mehr darauf hinausläuft, das 'bestimmte Personengruppen' per se
> > > glaubwürdig sind, und andere nicht.
> >
> > Niemand, deswegen ist es ja ein Beweiss. Dessen Korrektheit muss man
> > nicht beweisen.
>
> Denn sie ist allen 'wichtigen Leuten' self evident.
Ein korrekter Beweis sollte _allen_ evident sein. Soweit zur Theorie.
Jeder, der die Axiome der Aussagenlogik kennt, kann den Beweis verstehen.
In der Praxis scheitert das an der Komplexität der Software. Dass ein
einfacher Brute-Force-Primzahltest funktioniert, kann ich leicht
beweisen. Ich würde aber das hier voraussetzen:
- Eine Primzahl ist eine natürliche Zahl, die genau zwei Teiler hat.
- Hat eine Zahl a den Teiler t, so hat sie auch den Teiler a/t.
Daraus würde ich folgern:
- Angenommen, der kleinste Teiler >= 1 einer Zahl a sei x. Dann gilt:
x <= a/x (x ist der _kleinste_ Teiler >= 1!)
und damit
x * x <= a
- Alle Primzahlen außer der 2 und der 3 sind kongruent +1 oder -1 modulo
6.
Von nun an ist es trivial, zu zeigen (aber umständlich, es
aufzuschreiben), dass
bool isPrime (unsigned int a)
{
if ((a == 2) || (a == 3))
return 1;
if ((a <= 1) || (a % 2 == 0) || (a % 3 == 0))
return 0;
int d = 4;
for (unsigned int x = 5; x * x <= a; x += (d ^= 6))
if (a % x == 0)
return 0;
return 1;
}
korrekt ist und anhält für a < (2 ** 16 - 1) ** 2 + 1, wenn unsigned int
einen Wertebereich von 0 bis 2 ** 32 - 1 hat.
"Dummerweise" ist kaum ein Programm so einfach aufgebaut, so dass ein
Korrektheitsbeweis realistisch machbar ist. Zur Übung beweise mal mal die
Korrektheit von fortune, was noch ein relativ simples Programm ist.
Rainer Weikusat
> Scripsit illa aut ille Rainer Weikusat <weik...@students.uni-mainz.de>:
> > fam_Sch...@t-online.de (Felix Schlesinger) writes:
> > > > Wer beweist wie die Korrektheit des Korrektheitsbeweises so, das es
> > > > nicht mehr darauf hinausläuft, das 'bestimmte Personengruppen' per se
> > > > glaubwürdig sind, und andere nicht.
> > >
> > > Niemand, deswegen ist es ja ein Beweiss. Dessen Korrektheit muss man
> > > nicht beweisen.
> >
> > Denn sie ist allen 'wichtigen Leuten' self evident.
>
> Ein korrekter Beweis sollte _allen_ evident sein. Soweit zur Theorie.
> Jeder, der die Axiome der Aussagenlogik kennt, kann den Beweis
> verstehen.
Jeder, der C kann, versteht auch das Programm. Your point being?
Michael Bergbauer
> Michael Bergbauer <just-f...@noname.franken.de> schrieb:
> > Kannst du mir abgesehen davon ein Stueck Software zeigen, bei dem
> > nach der ersten Veroeffentlichung mit neuen Features keine Fehler
> > gefunden wurden? Wuerd mich wirklich interessieren, ob es sowas
> > gibt, und wenn ja, in welchem Umfeld
> Soweit ich weiss hat bisher niemand den Preis fuer das auffinden eines
> Fehlers in QMail beansprucht. Auch wenn man sonst geteilter Meinung zu
> DJBs Software sein kann. (Ich setze sie nicht mehr ein.)
Stimmt, ja. Dabei hab ich das Teil selbst laufen. Naja, es war Freitag,
und ich gelobe, beim naechsten mal erst zu denken, und dann zu posten.
Andreas Krey
>
>"Dummerweise" ist kaum ein Programm so einfach aufgebaut, so dass ein
>Korrektheitsbeweis realistisch machbar ist. Zur Übung beweise mal mal die
>Korrektheit von fortune, was noch ein relativ simples Programm ist.
Du hast auch noch vergessen nachzuweisen, daß das Compilat tatsächlich
das tut, was der abgeleitete Quellcode verspricht.
Andreas
Rainer Weikusat
Für die semantische Korrektheit ist das vollkommen uninteressant.
frank paulsen
damit nicht sowas passiert wie bei der inbetriebnahme des EStw in
Hamburg-Altona, als die angeblich korrekte software mit einem
stackfehler absemmelte und wochenlange verspaetungen die folgen waren?
http://userpage.fu-berlin.de/~dittbern/Archiv/PC_and_Railways.html#Altona_1
--
frobnicate foo
Jens Grivolla
> Rudolf Polzer <AntiATFiel...@durchnull.de> writes:
> > Ein korrekter Beweis sollte _allen_ evident sein. Soweit zur Theorie.
> > Jeder, der die Axiome der Aussagenlogik kennt, kann den Beweis
> > verstehen.
>
> Jeder, der C kann, versteht auch das Programm. Your point being?
Man reduziert die Überprüfung der semantischen Korrektheit eines
komplexen Programms auf die Überprüfung der syntaktischen Korrektheit
einzelner Ableitungsschritte.
Oder anders: Korrektheitsbeweise bilden eine berechenbare/
entscheidbare (und üblicherweise einfache) Sprache, während die
Sprache der semantisch korrekten Programme nicht nur viel komplexer,
sondern nicht einmal entscheidbar ist (schon allein, weil semantische
Korrektheit von der Intention des Programmierers abhängt).
Die Entscheidung, ob ein Beweisversuch in der Sprache der Korrektheits-
beweise ist (also einen korrekten Beweis darstellt), ist trivial (da
mit vertretbarem Aufwand entscheidbar). Wenn die Erkenntnis, dass
der "Beweis" ein Beweis ist, Aufschlüsse über die semantische
Korrektheit deines Programmes gibt, hast du damit tatsächlich etwas
erreicht.
Ciao,
Jens
Rainer Weikusat
> Rainer Weikusat <weik...@students.uni-mainz.de> writes:
> > Rudolf Polzer <AntiATFiel...@durchnull.de> writes:
> > > Ein korrekter Beweis sollte _allen_ evident sein. Soweit zur Theorie.
> > > Jeder, der die Axiome der Aussagenlogik kennt, kann den Beweis
> > > verstehen.
> >
> > Jeder, der C kann, versteht auch das Programm. Your point being?
>
> Man reduziert die Überprüfung der semantischen Korrektheit eines
> komplexen Programms auf die Überprüfung der syntaktischen Korrektheit
> einzelner Ableitungsschritte.
Tja ... solange Programme noch aus einzelnen Anweisungen bestehen und
eine interne Struktur haben, wird man das wohl so machen ...
> Oder anders: Korrektheitsbeweise bilden eine berechenbare/
> entscheidbare (und üblicherweise einfache) Sprache,
Anders ausgedrückt: Die Sprache ist nicht mächtig genug, um die
Ablauflogik des Programmes einfach auszudrücken (denn sonst würde man
sie ja auch zum programmieren und nicht zum onanieren verwenden),
deswegen werden 'Übersetzungen' zwangsläufig etwas aufgeblähter, weil
man das real zugrundeliegende Automatenmodell ja auch noch 'emulieren'
muß.
> Die Entscheidung, ob ein Beweisversuch in der Sprache der Korrektheits-
> beweise ist (also einen korrekten Beweis darstellt), ist trivial
Das sagt mir genau nichts darüber, ob beide Texte tatsächlich dasselbe
abbilden, das darf ich lediglich 'dem Übersetzer' glauben.
> Wenn die Erkenntnis, dass der "Beweis" ein Beweis ist, Aufschlüsse
> über die semantische Korrektheit deines Programmes gibt, hast du
> damit tatsächlich etwas erreicht.
Wenn 'ein Korrektheitsbeweis' jemandem, der die Originalsprache nicht
'sprechen' kann, ermöglicht, 'auch ein paar Bugs' zu finden, ist das
sicher nützlich, lediglich 'etwas überbewertet'.
F'up2 poster
Lutz Donnerhacke
>Felix von Leitner <usenet-...@fefe.de> writes:
>> Du wirst lachen, es gibt auch Software, bei denen überhaupt nie Fehler
>> gefunden werden.
>
Das ist in C nicht trivial. Da gibt es lange Threads zu, das korrekt zu
schreiben.
Lutz Donnerhacke
>Jeder, der C kann, versteht auch das Programm. Your point being?
Wie ist denn die Semantik von folgendem Programm?
int main(void) {
return printf("Hello world.\n");
}
Sebastian Posner
>> "Hello World"? SCNR
> Das ist in C nicht trivial. Da gibt es lange Threads zu, das korrekt zu
> schreiben.
Hattest du nicht mal eine Referenzimplementation geschrieben? Oder haben
mit meine Quellen Mist erzählt?
Sebastian
Felix Schlesinger
In C ist so praktsich nichts trivial. Einfach nur eine Zeile aus
einem Stream zu lesen und in z.B. eine Datei zu speichern ist in C
!trivial.
Ciao
Felix
PS: Schlussfolgerungen auf die Qualität der Sprache seien jedem selbst
überlassen.
Urs [Ayahuasca] Traenkner
> In C ist so praktsich nichts trivial. Einfach nur eine Zeile aus
> einem Stream zu lesen und in z.B. eine Datei zu speichern ist in C
> !trivial.
> PS: Schlussfolgerungen auf die Qualität der Sprache seien jedem selbst
> überlassen.
Liest sich so: C ist Scheisse.
(ich muss zu meiner absoluten Schande gestehen, nur (T/B)Pascal zu
koennen)
Gruss Urs...
--
Ein Buch ist wie ein Spiegel: wenn ein
Affe hineinsieht, so kann kein Apostel
herausgucken.
Georg Christoph Lichtenberg
Immo 'FaUl' Wehrenberg
> begin Lutz Donnerhacke schrieb
>> * Michael Bergbauer wrote:
>>>Felix von Leitner <usenet-...@fefe.de> writes:
>>>> Du wirst lachen, es gibt auch Software, bei denen überhaupt nie Fehler
>>>> gefunden werden.
>>>
>>>"Hello World"? SCNR
>>
>> Das ist in C nicht trivial. Da gibt es lange Threads zu, das korrekt zu
>> schreiben.
>
> In C ist so praktsich nichts trivial. Einfach nur eine Zeile aus
> einem Stream zu lesen und in z.B. eine Datei zu speichern ist in C
> !trivial.
#include <stdio.h>
#include <stdlib.h>
int main (void) {
FILE *datei;
char c;
if (!(datei = fopen ("datei", "w"))) return EXIT_FAILURE;
while ((c = fgetc (stdin)) != '\n')
if (feof (stdin) || !fputc (c, datei)) return EXIT_FAILURE;
return 0;
}
ist !trivial?
Das gleiche in Perl:
use strict;
use warnings;
open datei, ">datei" or die;
$_ = <stdin>;
chomp;
print datei $var or die;
hat 3 Zeilen weniger, zugegeben. Aber Perl ist fuer solche sachen entwikelt
worden.
FaUl
end
This article does not support incompatible and broken newsreaders.
--
Ich kenn mehr die 90/10-Regeln...
Für 90% der Arbeit braucht man 90 % der Zeit.
Für die restlichen 10% Arbeit braucht man die anderen 90% der Zeit.
[Sebastian Posner in dasr]
Felix Schlesinger
> begin followup to the posting of Felix Schlesinger
>> In C ist so praktsich nichts trivial. Einfach nur eine Zeile aus
>> einem Stream zu lesen und in z.B. eine Datei zu speichern ist in C
>> !trivial.
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int main (void) {
> FILE *datei;
> char c;
> if (!(datei = fopen ("datei", "w"))) return EXIT_FAILURE;
> while ((c = fgetc (stdin)) != '\n')
> if (feof (stdin) || !fputc (c, datei)) return EXIT_FAILURE;
> return 0;
> }
>
> ist !trivial?
jein, aber die Aufgabe war es auch eine ganze Zeile einzulesen (in eine
Datenstruktur und sie *danach* auszugeben oder halt irgendwas anderes
damit zu machen. Wenn man das richtig machen will, muss einige Dinge
berücksichtigen die nicht mehr trivial (bezogen auf die Einfachheit der
Aufgabe) sind.
> Das gleiche in Perl:
>
> use strict;
> use warnings;
>
> open datei, ">datei" or die;
> $_ = <stdin>;
> chomp;
> print datei $var or die;
>
> hat 3 Zeilen weniger, zugegeben. Aber Perl ist fuer solche sachen entwikelt
> worden.
Die 3 Zeilen sind egal. Wichtig ist, das du hier schreibst was du
meinst, während du oben einfach Zeichen liest und schreibst. Dabei kommt
dann halt (zufällig) das Kopieren einer Zeile raus. Das dabei leicher
Fehler auftretten ist offensichtlich.
Ciao
Felix
PS: Und es gibt natürlich dafür auch noch bessere Sprachen als Perl.
Immo 'FaUl' Wehrenberg
> begin Immo 'FaUl' Wehrenberg schrieb
>> #include <stdlib.h>
>> int main (void) {
>> FILE *datei;
>> char c;
>> if (!(datei = fopen ("datei", "w"))) return EXIT_FAILURE;
>> while ((c = fgetc (stdin)) != '\n')
>> if (feof (stdin) || !fputc (c, datei)) return EXIT_FAILURE;
>> return 0;
>> }
>> ist !trivial?
> jein, aber die Aufgabe war es auch eine ganze Zeile einzulesen (in eine
> Datenstruktur und sie *danach* auszugeben oder halt irgendwas anderes
> damit zu machen. Wenn man das richtig machen will, muss einige Dinge
> berücksichtigen die nicht mehr trivial (bezogen auf die Einfachheit der
> Aufgabe) sind.
Genau das habe ich gemacht. Du wirst lachen aber stdin ist (zumindest bei
der Glibc und der Dietlibc) ein pointer auf eine Datenstruktur und die wird
erst beim Beenden des Programmes ausgegeben.
> PS: Und es gibt natürlich dafür auch noch bessere Sprachen als Perl.
Bash?
PS: ich haette das so gemacht:
$ perl -e "print chomp (my $x = <stdin>)" >datei
allerdings ist das nihct die saubere loesung und funktioniert in C ganz
aehnlich
FaUl
end
This article does not support incompatible and broken newsreaders.
--
Bei meinem Notebook war es von vorneherein deaktiviert, zumindest beim
vorinstallierten Windows ME. PCMCIA Karte reingesteckt, das Laempchen
der Festplatte hat kurz geleuchtet, Bildschirm wurde schwarz, Notebook
hat nicht mehr reagiert. [Norbert Tretkowski in dasr]
Dietz Proepper
Der Thread beweist aber eher was herauskommt wenn man Software und
Analfixierung, gewürzt mit einer Portion hirntoter API, kombiniert.
Dietz
Dietz Proepper
Diese ist ohne weitere Informationen, z.B. über verwendete libc, Compiler,
Betriebssystem nicht ermittelbar. C eben.
Zudem, in welcher Sprache hätten's Ihre Semantik denn gerne?
Dietz
Rainer Weikusat
> * Rainer Weikusat wrote:
> >Jeder, der C kann, versteht auch das Programm. Your point being?
>
> Wie ist denn die Semantik von folgendem Programm?
>
> int main(void) {
"Undefiniert"
Lutz Donnerhacke
Nein. Hans Bonfigt hatte es mal versucht und das gabe Threads ...
Lutz Donnerhacke
>#include <stdio.h>
>#include <stdlib.h>
>
>int main (void) {
> FILE *datei;
> char c;
> if (!(datei = fopen ("datei", "w"))) return EXIT_FAILURE;
> while ((c = fgetc (stdin)) != '\n')
> if (feof (stdin) || !fputc (c, datei)) return EXIT_FAILURE;
> return 0;
>}
>
>ist !trivial?
Es ist falsch.
Das letzte Zeichen einer Zeile, die kein '\n' enthält wird nicht kopiert.
Was ist eigentlich '\n'? Ein Zeilentrenner ist es nicht, denn AmigaOS und
Terminals benutze dafür '\r' und MS-DOS, Unix-Telnet etc. benutzen "\r\n".
Sowohl fopen als auch fgetc und fputc können von Interrupts unterbrochen
werden und müssen in diesem Fall neu versucht werden.
Ebenso fehlt ein fclose und dessen Fehlerbehandlung (z.B. Platte voll).
Darüberhinaus existiert eine Racecondition zwischen feof und fgetc.
Ebenso ist der Rückgabewert im Erfolgsfall falsch. Bei VMS erwartet das
System einen Rückgabewert, dessen niederwertigstes Bit auf eins gesetzt
wird, wenn die Aktion erfolgreich war.
Möchtest Du es nochmal probieren?
>Das gleiche in Perl:
>
>use strict;
>use warnings;
>
>open datei, ">datei" or die;
>$_ = <stdin>;
>chomp;
>print datei $var or die;
>
>hat 3 Zeilen weniger, zugegeben. Aber Perl ist fuer solche sachen entwikelt
>worden.
Und es ist wieder falsch.
open (datei, ">datei") || die "datei: $!\n";
$_ = <stdin> || die "read stdin: $!\n";
chomp;
print datei ($var) || die "output: $!\n";
close (datei) || die "output: $!\n";
Das Interrupthandling von Perl kenne ich nicht auswendig.
Felix Schlesinger
>> Datenstruktur und sie *danach* auszugeben oder halt irgendwas anderes
>> damit zu machen. Wenn man das richtig machen will, muss einige Dinge
>> berücksichtigen die nicht mehr trivial (bezogen auf die Einfachheit der
>> Aufgabe) sind.
>
> Genau das habe ich gemacht. Du wirst lachen aber stdin ist (zumindest bei
> der Glibc und der Dietlibc) ein pointer auf eine Datenstruktur und die wird
> erst beim Beenden des Programmes ausgegeben.
Das ist schon fast schrecklich wie sehr du das C-Klischee
erfüllst. Anstatt eine nachvollziehbare korrekte Lösung abzuliefern,
schreibst du ein Programm das auf den speziellen Eigenarten einer
Implementation basiert und im Hintergrund implizit irgendeinen Voodoo
durchführt. Guter Stil ist das nicht.
Ciao
Felix
PS: Ich bin gespannt ob jemand eine korrekte Lösung in C findet. (Oder
ob es sowas überhaupt gibt)
Felix von Leitner
> >"Hello World"? SCNR
> Das ist in C nicht trivial. Da gibt es lange Threads zu, das korrekt zu
> schreiben.
#include <stdio.h>
int main() {
puts("Hallo, Welt!");
return 0;
}
HTH. HAND.
Lutz Donnerhacke
Wo ist die Fehlerbehandlung von puts? Wo ist die Abhandlung von EINTR?
Wo ist der erfolgabhängige Rückgabewert, der vom OS auch so verstanden wird?
Felix von Leitner
> >#include <stdlib.h>
> >
> >int main (void) {
> > FILE *datei;
> > char c;
> > if (!(datei = fopen ("datei", "w"))) return EXIT_FAILURE;
> > while ((c = fgetc (stdin)) != '\n')
> > if (feof (stdin) || !fputc (c, datei)) return EXIT_FAILURE;
> > return 0;
> >}
> Es ist falsch.
> Das letzte Zeichen einer Zeile, die kein '\n' enthält wird nicht kopiert.
feof testet, ob der end-of-file Indikator gesetzt ist. Der ist gesetzt,
nachdem ein read() 0 zurückgeliefert hat, d.h. _nachdem_ ein fgetc() EOF
zurückgeliefert hat, nicht davor. Das führt zu lustigen Verrenkungen,
die man z.B. prima in libbz2 sehen kann. Kurz gesagt: deine Beobachtung
stimmt nicht.
> Was ist eigentlich '\n'?
Eine Konstante vom Typ "char".
> Sowohl fopen als auch fgetc und fputc können von Interrupts unterbrochen
> werden und müssen in diesem Fall neu versucht werden.
Das ist systemabhängig.
> Ebenso fehlt ein fclose und dessen Fehlerbehandlung (z.B. Platte voll).
ACK.
> Darüberhinaus existiert eine Racecondition zwischen feof und fgetc.
Nein.
> Ebenso ist der Rückgabewert im Erfolgsfall falsch. Bei VMS erwartet das
> System einen Rückgabewert, dessen niederwertigstes Bit auf eins gesetzt
> wird, wenn die Aktion erfolgreich war.
VMS ist obsolet.
Felix
Felix von Leitner
> int main(void) {
> return printf("Hello world.\n");
> }
"falsch". Main nimmt genau zwei Argumente. Man darf das dank K&R
Rückwärtskompatibilität auch als "main()" abkürzen, wenn man die
Argumente nicht benutzen will, aber nicht als "main(void)".
Felix
Lutz Donnerhacke
>
>feof testet, ob der end-of-file Indikator gesetzt ist. Der ist gesetzt,
>nachdem ein read() 0 zurückgeliefert hat, d.h. _nachdem_ ein fgetc() EOF
>zurückgeliefert hat, nicht davor. Das führt zu lustigen Verrenkungen,
>die man z.B. prima in libbz2 sehen kann. Kurz gesagt: deine Beobachtung
>stimmt nicht.
Interessant. Dann werde ich mein 'tail -f' doch weiterhin nicht mit C
implementieren.
Felix von Leitner
> > int main() {
> > puts("Hallo, Welt!");
> > return 0;
> > }
> Wo ist die Fehlerbehandlung von puts? Wo ist die Abhandlung von EINTR?
> Wo ist der erfolgabhängige Rückgabewert, der vom OS auch so verstanden wird?
Das steht alles nicht in meiner Spezifikation von "Hallo, Welt".
Und deswegen ist es fruchtlos, diese Art von Diskussion überhaupt zu
führen. Jeder kann jederzeit mit weiteren Anforderungen kommen und
behaupten, das müßte auch noch behandelt werden.
Aber im Ernst: der Rückgabewert von puts ist wertlos. puts schreibt in
den stdio-Buffer und returnt _immer_ strlen("Hallo, Welt!"), weil ein
kleinerer stdio-Buffer keinen Sinn macht und daher bei keinem System in
der Praxis vorkommt. Das Schreiben findet also in dem impliziten
fflush(0) statt, dessen Return-Code man nicht sieht.
Felix
Andreas Krennmair
> > Was ist eigentlich '\n'?
>
> Eine Konstante vom Typ "char".
Kurioserweise sind Character-Konstante vom Typ int (IIRC).
mfg, ak
--
Select how many previous history files should be kept?
yes, no, individual
-- Debian CVS package configuration
Lutz Donnerhacke
ANSI-X3J11 sagt:
5.1.2.2.1 Program startup
1 The function called at program startup is named main. The implementation
declares no prototype for this function. It shall be defined with a
return type of int and with no parameters:
int main(void) {
/* ... */
}
or with two parameters (referred to here as argc and argv, though any
names may be used, as they are local to the function in which they are
declared):
int main(int argc, char *argv[]) {
/* ... */
} or
equivalent° or in some other implementation-defined manner.
O Thus, int can be replaced by a typedef name defined as int, or the type
of argv can be written as char ** argv, and so on.
Felix von Leitner
> >nachdem ein read() 0 zurückgeliefert hat, d.h. _nachdem_ ein fgetc() EOF
> >zurückgeliefert hat, nicht davor. Das führt zu lustigen Verrenkungen,
> >die man z.B. prima in libbz2 sehen kann. Kurz gesagt: deine Beobachtung
> >stimmt nicht.
> Interessant. Dann werde ich mein 'tail -f' doch weiterhin nicht mit C
> implementieren.
Mach mal ein strace auf tail -f! Der macht wiederholt fseek, um so den
EOF Indikator zurückzusetzen. Das ist echt zum Totlachen.
Felix
Lutz Donnerhacke
Eben. Man muß STDIO meiden.
Felix von Leitner
> >Rückwärtskompatibilität auch als "main()" abkürzen, wenn man die
> >Argumente nicht benutzen will, aber nicht als "main(void)".
> ANSI-X3J11 sagt:
Du hast Recht, ich hatte die C FAQ falsch im Hinterkopf. main(void) ist
erlaubt.
Felix
Rainer Weikusat
> * Felix von Leitner wrote:
> > #include <stdio.h>
> > int main() {
> > puts("Hallo, Welt!");
> > return 0;
> > }
>
> Wo ist die Fehlerbehandlung von puts? Wo ist die Abhandlung von
> EINTR?
----------------------------
A signal can arrive and be handled while an I/O primitive such as
`open' or `read' is waiting for an I/O device. If the signal handler
returns, the system faces the question: what should happen next?
POSIX specifies one approach: make the primitive fail right away.
The error code for this kind of failure is `EINTR'. This is flexible,
but usually inconvenient. Typically, POSIX applications that use signal
handlers [...]
----------------------------
Immo 'FaUl' Wehrenberg
[meine Version]
> Das letzte Zeichen einer Zeile, die kein '\n' enthält wird nicht kopiert.
>
> Was ist eigentlich '\n'? Ein Zeilentrenner ist es nicht,
"new-line escape sequence". Zumindest laut ISO/IEC 9899:1999
Ich habe das bis jetzt so ausgelegt, das \n eben immer passt. Habe ich das
falsch verstanden?
> Sowohl fopen als auch fgetc und fputc können von Interrupts unterbrochen
> werden und müssen in diesem Fall neu versucht werden.
Wenn fgetc oder fputc unterbrochen wird schlaegt es fehl und damit bricht das
Programm (mit EXIT_FAILURE) ab, da das verhalten nicht genauer in der
Aufgabenstellung spezifieziert war ist das voellig legal.
> Ebenso fehlt ein fclose und dessen Fehlerbehandlung (z.B. Platte voll).
fclose wird implizit beim beenden aufgerufen. Fehlerbehandlung: korrigiert.
> Darüberhinaus existiert eine Racecondition zwischen feof und fgetc.
-v
> Ebenso ist der Rückgabewert im Erfolgsfall falsch. Bei VMS erwartet das
> System einen Rückgabewert, dessen niederwertigstes Bit auf eins gesetzt
> wird, wenn die Aktion erfolgreich war.
fixed
> Möchtest Du es nochmal probieren?
Ja:
#include <stdio.h>
#include <stdlib.h>
int main (void) {
FILE *datei;
char c;
if (!(datei = fopen ("datei", "w"))) return EXIT_FAILURE;
while ((c = fgetc (stdin)) != '\n' && c != EOF && c != '\n')
if (!fputc (c, datei)) return EXIT_FAILURE;
if (fflush(datei)) return EXIT_FAILURE;
return EXIT_SUCCESS;
}
>>Das gleiche in Perl:
[...]
> Und es ist wieder falsch.
Du siehst, es liegt nicht an C ;).
[Korrigierte Version]
Da ist zwar ganzschoen viel verbose drin, aber ok.
FaUl
end
This article does not support incompatible and broken newsreaders.
--
Warnung: Windows 2000 Advanced Server stürzt ab.
Sind Sie einverstanden?
(J)a (N)atürlich (I)mmer doch
Immo 'FaUl' Wehrenberg
[meine Version]
> Das letzte Zeichen einer Zeile, die kein '\n' enthält wird nicht kopiert.
>
> Was ist eigentlich '\n'? Ein Zeilentrenner ist es nicht,
"new-line escape sequence". Zumindest laut ISO/IEC 9899:1999
Ich habe das bis jetzt so ausgelegt, das \n eben immer passt. Habe ich das
falsch verstanden?
> Sowohl fopen als auch fgetc und fputc können von Interrupts unterbrochen
> werden und müssen in diesem Fall neu versucht werden.
Wenn fgetc oder fputc unterbrochen wird schlaegt es fehl und damit bricht das
Programm (mit EXIT_FAILURE) ab, da das verhalten nicht genauer in der
Aufgabenstellung spezifieziert war ist das voellig legal.
> Ebenso fehlt ein fclose und dessen Fehlerbehandlung (z.B. Platte voll).
fclose wird implizit beim beenden aufgerufen. Fehlerbehandlung: korrigiert.
> Darüberhinaus existiert eine Racecondition zwischen feof und fgetc.
-v
> Ebenso ist der Rückgabewert im Erfolgsfall falsch. Bei VMS erwartet das
> System einen Rückgabewert, dessen niederwertigstes Bit auf eins gesetzt
> wird, wenn die Aktion erfolgreich war.
fixed
> Möchtest Du es nochmal probieren?
Ja:
#include <stdio.h>
#include <stdlib.h>
int main (void) {
FILE *datei;
char c;
if (!(datei = fopen ("datei", "w"))) return EXIT_FAILURE;
while ((c = fgetc (stdin)) != '\n' && c != EOF)
if (!fputc (c, datei)) return EXIT_FAILURE;
return fflush (datei) ? EXIT_FAILURE : EXIT_SUCCESS;
}
>>Das gleiche in Perl:
[...]
> Und es ist wieder falsch.
Du siehst, es liegt nicht an C ;).
[Korrigierte Version]
Da ist zwar ganzschoen viel verbose drin, aber ok.
FaUl
end
This article does not support incompatible and broken newsreaders.
--
Lutz Donnerhacke
>[meine Version]
>
>"new-line escape sequence". Zumindest laut ISO/IEC 9899:1999
Das ist die Bedeutung des Zeichens nach dieser Norm. Warum sollte diese Norm
auf dem Zielsystem gelten? Steht das in der Spec von C? (In der Spec von Ada
steht da einiges zu.)
>Ich habe das bis jetzt so ausgelegt, das \n eben immer passt. Habe ich das
>falsch verstanden?
Du kennst die Zeilenende-Kennung nicht, sondern benutze etwas, was auf
Deinem System typisch ist. Das ist nicht portabel. Es ist schon nicht
portabel, wenn Du auf Deinem System über eine Netzschnittstelle arbeitest
(Serial benutzt '\r' und Telnet "\r\n" (BTW: '\r' ist bei Telnet kein
gültiges Zeichen, sondern nur die Tupel "\r\n" und "\r\0".))
>> Sowohl fopen als auch fgetc und fputc können von Interrupts unterbrochen
>> werden und müssen in diesem Fall neu versucht werden.
>
>Wenn fgetc oder fputc unterbrochen wird schlaegt es fehl und damit bricht
>das Programm (mit EXIT_FAILURE) ab, da das verhalten nicht genauer in der
>Aufgabenstellung spezifieziert war ist das voellig legal.
Für fputs stimmt das, für fgetc nicht. Da Signale aber jederzeit kommen
können, ist es eine Selbstverständlichkeit, von deren Existenz nicht die
Semantik des Programs abhängig zu machen. Diese Fehlfunktion wäre
überraschend.
>> Darüberhinaus existiert eine Racecondition zwischen feof und fgetc.
>
>-v
Siehe Diskussion mit Fefe. Er weiß mehr über die impliziten Statii von Stdio.
>#include <stdio.h>
>#include <stdlib.h>
>
>int main (void) {
> FILE *datei;
> char c;
*Patsch* Falsch.
> if (!(datei = fopen ("datei", "w"))) return EXIT_FAILURE;
> while ((c = fgetc (stdin)) != '\n' && c != EOF)
> if (!fputc (c, datei)) return EXIT_FAILURE;
> return fflush (datei) ? EXIT_FAILURE : EXIT_SUCCESS;
>}
Ob Du fflush oder fclose machst, ist doch egal, also mache bitte fclose.
Und nun behandle bitte EINTR noch. Danke.
>>>Das gleiche in Perl:
>[...]
>> Und es ist wieder falsch.
>
>Du siehst, es liegt nicht an C ;).
Doch. In Ada ist es sauber spezifiziert.
Und nun bitte eine korrekt C-Version für diese triviale Aufgabe.
Rainer Weikusat
> * Immo 'FaUl' Wehrenberg wrote:
> >begin followup to the posting of Lutz Donnerhacke
> >
> >"new-line escape sequence". Zumindest laut ISO/IEC 9899:1999
>
> Das ist die Bedeutung des Zeichens nach dieser Norm. Warum sollte diese Norm
> auf dem Zielsystem gelten?
Warum sollte eine beliebige Ada-Norm irgendwo gelten? Vielleicht weil
sie implementiert wurde? Darf man das dann verallgemeinern?
> >Ich habe das bis jetzt so ausgelegt, das \n eben immer passt. Habe ich das
> >falsch verstanden?
>
> Du kennst die Zeilenende-Kennung nicht, sondern benutze etwas, was auf
> Deinem System typisch ist. Das ist nicht portabel.
C ist per Definition nicht portabel, lediglich C-Programme sind das
ggf innerhalb der Systeme, auf die sie portiert wurden (autconf ist
ein framework, in das man systemspezifischen Code allgemein einhängen
kann, keine 'magische Portabilitätshilfe').
> Es ist schon nicht portabel, wenn Du auf Deinem System über eine
> Netzschnittstelle arbeitest (Serial benutzt '\r' und Telnet "\r\n"
> (BTW: '\r' ist bei Telnet kein gültiges Zeichen, sondern nur die
> Tupel "\r\n" und "\r\0".))
Siehe oben. Falls ich 'telnet' sprechen möchte, suche ich mir einen
Prozeß, der die Protokolldetails für mich abhandelt und kümmere mich
ansonsten um meine Probleme.
> Für fputs stimmt das, für fgetc nicht. Da Signale aber jederzeit kommen
> können, ist es eine Selbstverständlichkeit, von deren Existenz nicht die
> Semantik des Programs abhängig zu machen.
Falls die c-library implizit undokumentiert signal handler einsetzt,
wünsche ich dem Programmierer in seinem Interesse, das er damit
klargekommen ist :->.
> Diese Fehlfunktion wäre überraschend.
So kann man das auch sehen.
> >#include <stdio.h>
> >#include <stdlib.h>
> >
> >int main (void) {
> > FILE *datei;
> > char c;
>
> *Patsch* Falsch.
s/char/int/
Lutz Donnerhacke
>lu...@iks-jena.de (Lutz Donnerhacke) writes:
>> * Immo 'FaUl' Wehrenberg wrote:
>> >begin followup to the posting of Lutz Donnerhacke
>> >> Was ist eigentlich '\n'? Ein Zeilentrenner ist es nicht,
>> >
>> >"new-line escape sequence". Zumindest laut ISO/IEC 9899:1999
>>
>> Das ist die Bedeutung des Zeichens nach dieser Norm. Warum sollte diese Norm
>> auf dem Zielsystem gelten?
>
>Warum sollte eine beliebige Ada-Norm irgendwo gelten?
Weil es sonst irgendwas, aber kein Ada ist.
'\n' in C ist zwar X3J11, aber kein Zeilentrenner auf dem Zielsystem.
'Ada.Text_IO.New_Line;' ist Ada und auf dem Zielsystem ein Zeilentrenner.
>Vielleicht weil sie implementiert wurde? Darf man das dann
>verallgemeinern?
Was in der Norm steht, ist zugesichert. Man darf aber nicht irgendeine Norm
zitieren, wenn man nicht belegen kann, daß sie auch angewendet wird. Niemand
hatte ISO/IEC 9899:1999 vorausgesetzt, sondern X3J11.
>> >Ich habe das bis jetzt so ausgelegt, das \n eben immer passt. Habe ich das
>> >falsch verstanden?
>>
>> Du kennst die Zeilenende-Kennung nicht, sondern benutze etwas, was auf
>> Deinem System typisch ist. Das ist nicht portabel.
>
>C ist per Definition nicht portabel,
X3J11 legt fest, auf was Du Dich verlassen kannst. Bei MIX ist nicht mal
klar, ob Du auf einem Binary oder Dezimalsystem arbeitest und trotzdem kann
man damit portabel programmieren. Und so ein Hello World wirst Du doch noch
portabel hinbekommen, oder? Sollte C das nicht schaffen?
>> Es ist schon nicht portabel, wenn Du auf Deinem System über eine
>> Netzschnittstelle arbeitest (Serial benutzt '\r' und Telnet "\r\n"
>> (BTW: '\r' ist bei Telnet kein gültiges Zeichen, sondern nur die
>> Tupel "\r\n" und "\r\0".))
>
>Siehe oben. Falls ich 'telnet' sprechen möchte, suche ich mir einen
>Prozeß, der die Protokolldetails für mich abhandelt und kümmere mich
>ansonsten um meine Probleme.
Dein Problem ist ein Hello World in C zu schreiben. Portabel. Nach X3J11.
>> Für fputs stimmt das, für fgetc nicht. Da Signale aber jederzeit kommen
>> können, ist es eine Selbstverständlichkeit, von deren Existenz nicht die
>> Semantik des Programs abhängig zu machen.
>
>Falls die c-library implizit undokumentiert signal handler einsetzt,
>wünsche ich dem Programmierer in seinem Interesse, das er damit
>klargekommen ist :->.
Da sie es aber nicht tut, ist es Dein Job. Auf!
Immo 'FaUl' Wehrenberg
> * Immo 'FaUl' Wehrenberg wrote:
>>> Was ist eigentlich '\n'? Ein Zeilentrenner ist es nicht,
>>"new-line escape sequence". Zumindest laut ISO/IEC 9899:1999
> Das ist die Bedeutung des Zeichens nach dieser Norm. Warum sollte diese Norm
> auf dem Zielsystem gelten?
ISO/IEC 9899:1999 ist AFAIK die zur Zeit gueltige C-Norm. Aber ich diskutiere
das auch gerne in de.comp.lang.c oder de.comp.standards. Ggf bitte fup2 setzen!
> Steht das in der Spec von C?
ISO/IEC 9899:1999 _ist_ die Spec von C.
>>Ich habe das bis jetzt so ausgelegt, das \n eben immer passt. Habe ich das
>>falsch verstanden?
> Du kennst die Zeilenende-Kennung nicht, sondern benutze etwas, was auf
> Deinem System typisch ist. Das ist nicht portabel.
'\n' steht auf Unix wie auf AmigaOS wie auf MSDOS fuer einen Zeilenumbruch.
So stehts im Standard.
>>> [EINTR]
>>Wenn fgetc oder fputc unterbrochen wird schlaegt es fehl und damit bricht
>>das Programm (mit EXIT_FAILURE) ab, da das verhalten nicht genauer in der
>>Aufgabenstellung spezifieziert war ist das voellig legal.
> Für fputs stimmt das, für fgetc nicht.
Doch:
| If a read error occurs, the error indicator for the stream is set and the
| fgetc function returns EOF.246)
> Da Signale aber jederzeit kommen
> können, ist es eine Selbstverständlichkeit, von deren Existenz nicht die
> Semantik des Programs abhängig zu machen.
Mein Programm laeuft zufaellig auch auf Systemen die garkeine Signale
haben. Diese Systeme haben selbstverstaendlich auch keine Moeglichkeit
Signale auszuwaehrten. Deswegen ignoriert man Signale eben einfach.
> Diese Fehlfunktion wäre überraschend.
es ist keine Fehlfunktion.
>>#include <stdio.h>
>>#include <stdlib.h>
>>
>>int main (void) {
>> FILE *datei;
>> char c;
> *Patsch* Falsch.
int c;
>> if (!(datei = fopen ("datei", "w"))) return EXIT_FAILURE;
>> while ((c = fgetc (stdin)) != '\n' && c != EOF)
>> if (!fputc (c, datei)) return EXIT_FAILURE;
if (c != '\n' && feof (stdin)) return EXIT_FAILURE;
>> return fflush (datei) ? EXIT_FAILURE : EXIT_SUCCESS;
>>}
> Ob Du fflush oder fclose machst, ist doch egal, also mache bitte fclose.
Warum?
> Und nun behandle bitte EINTR noch. Danke.
Nein, EINTR ist nicht Portabel.
FaUl
--
Wenn ein Autor 1000 Seiten benötigt, um die Konfiguration eines Programmes zu
erläutern, dann würden wir von diesem Programm erwarten, dass es etwas mehr
kann als Mails zu transportieren. Vielleicht kann sendmail dies auch, keine
Ahnung, wir haben das Buch wieder weggel<eg>t. [T-Online-Team ueber sendmail]
Stefan Reuther
Lutz Donnerhacke <lu...@iks-jena.de> wrote:
> * Rainer Weikusat wrote:
>>lu...@iks-jena.de (Lutz Donnerhacke) writes:
>>> * Immo 'FaUl' Wehrenberg wrote:
>>> >begin followup to the posting of Lutz Donnerhacke
>>> >> Was ist eigentlich '\n'? Ein Zeilentrenner ist es nicht,
>>> >
>>> >"new-line escape sequence". Zumindest laut ISO/IEC 9899:1999
>>> [...]
> Weil es sonst irgendwas, aber kein Ada ist.
> '\n' in C ist zwar X3J11, aber kein Zeilentrenner auf dem Zielsystem.
Doch.
# 5.2.2 Character display semantics
#
# [#2] Alphabetic escape sequences representing nongraphic
# characters in the execution character set are intended to
# produce actions on display devices as follows:
#
# \n (new line) Moves the active position to the initial
# position of the next line.
Welchen numerischen Wert \n hat und wie dieses \n auf magische
Weise in einen Zeilenumbruch verwandelt wird, kann dem Programmierer
egal sein.
> Dein Problem ist ein Hello World in C zu schreiben. Portabel. Nach X3J11.
#include <stdio.h>
int main() {
puts("Hello, world");
}
>>> Für fputs stimmt das, für fgetc nicht. Da Signale aber jederzeit kommen
>>> können, ist es eine Selbstverständlichkeit, von deren Existenz nicht die
>>> Semantik des Programs abhängig zu machen.
>>
>>Falls die c-library implizit undokumentiert signal handler einsetzt,
>>wünsche ich dem Programmierer in seinem Interesse, das er damit
>>klargekommen ist :->.
> Da sie es aber nicht tut, ist es Dein Job. Auf!
Ich kann jetzt hier nichts finden, das ausdrücklich verbietet
oder legalisiert, daß ein "fgetc" oder "fread" von einem Signal
unter- und abgebrochen werden kann. Als Fehlerbedingungen gibt
es nur EOF und "read error". Ob eine C-Library also nach
Signalen automatisch wieder aufsetzt ist ein "Quality of Implementation
Issue". Wenn ich nicht will, daß Signale mir meine freads kaputt
machen, muß ich halt eine Lib nehmen, bei der das nicht so ist. Gibt's
nicht? Schade. Aber was kann die Programmiersprache C dafür?
Stefan
Lutz Donnerhacke
>Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>> '\n' in C ist zwar X3J11, aber kein Zeilentrenner auf dem Zielsystem.
>
>Doch.
>
># 5.2.2 Character display semantics
Danke. Höchst interessant, wie Unmögliches genormt wird. Nunja. Danke
trotzdem.
>> Dein Problem ist ein Hello World in C zu schreiben. Portabel. Nach X3J11.
>
>#include <stdio.h>
>int main() {
> puts("Hello, world");
>}
Returncode? Fehlerbeandlung?
>Ich kann jetzt hier nichts finden, das ausdrücklich verbietet
>oder legalisiert, daß ein "fgetc" oder "fread" von einem Signal
>unter- und abgebrochen werden kann. Als Fehlerbedingungen gibt
>es nur EOF und "read error". Ob eine C-Library also nach
>Signalen automatisch wieder aufsetzt ist ein "Quality of Implementation
>Issue". Wenn ich nicht will, daß Signale mir meine freads kaputt
>machen, muß ich halt eine Lib nehmen, bei der das nicht so ist. Gibt's
>nicht? Schade. Aber was kann die Programmiersprache C dafür?
Sie normt das Verhalten nicht und ist somit in dem Bereich völlig nutzlos.
Immo 'FaUl' Wehrenberg
>>#include <stdio.h>
>>int main() {
>> puts("Hello, world");
>>}
> Returncode? Fehlerbeandlung?
Implizit 0
nicht noetig. Entweder es funktioniert oder nicht.
FaUl
--
Wenn ein Autor 1000 Seiten benötigt, um die Konfiguration eines Programmes zu
erläutern, dann würden wir von diesem Programm erwarten, dass es etwas mehr
kann als Mails zu transportieren. Vielleicht kann sendmail dies auch, keine
Ahnung, wir haben das Buch wieder weggel<eg>t. [T-Online-Team in toti]
Jens Hektor
> nicht noetig. Entweder es funktioniert oder nicht.
Richtig. So hab ich das mal früher auch gesehen.
Im folgenden Programm ist auch ein dicker Hund:
int main ( void ) { write ( 0, "\07", 1 ) ; return 0 ; }
--
Jens Hektor, RWTH Aachen, Rechenzentrum, Seffenter Weg 23, 52074 Aachen
Computing Center Technical University Aachen, network operation & security
mailto:hek...@RZ.RWTH-Aachen.DE, Tel.: +49 241 80 29206, Raum: 2.35
Immo 'FaUl' Wehrenberg
> int main ( void ) { write ( 0, "\07", 1 ) ; return 0 ; }
-v
Andreas Krennmair
> Jens Hektor schrob:
> > int main ( void ) { write ( 0, "\07", 1 ) ; return 0 ; }
>
> -v
Auf fd 0 rausschreiben ist semantisch nicht 100%ig korrekt, IMO. Aber
macht nix, 0 ist ja defaultmaessig O_RDWR geoeffnet, und fd 1 und 2 nur
jeweils ein Duplikat von fd 0. Wie portabel das allerdings ist, sei
dahingestellt.
mfg, ak
--
A one-character regular expression is a regular expression that
matches whatever the one-character regular expression matches.
-- Sun regexp manpage
Stefan Reuther
Lutz Donnerhacke <lu...@iks-jena.de> wrote:
> * Stefan Reuther wrote:
>>Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>>> '\n' in C ist zwar X3J11, aber kein Zeilentrenner auf dem Zielsystem.
>>
>>Doch.
>>
>># 5.2.2 Character display semantics
> Danke. Höchst interessant, wie Unmögliches genormt wird. Nunja. Danke
> trotzdem.
Besseren Vorschlag? Ich finde es jedenfalls wesentlich
besser, Zeilenumbrüche derart in Strings zu codieren, als
wie in Pascal für einen Zeilenumbruch eine extra Funktion
("Writeln") aufrufen zu müssen.
Für Terminal-Steuercodes (vt100 aka "ansi.sys") gibt's ja
wohl auch 'ne Norm :)
>>> Dein Problem ist ein Hello World in C zu schreiben. Portabel. Nach X3J11.
>>
>>#include <stdio.h>
>>int main() {
>> puts("Hello, world");
>>}
> Returncode?
Meinereiner ist C++-verwöhnt, aber in C99 gibt's das
implizite "return 0" inzwischen auch :)
> Fehlerbeandlung?
int main() {
return puts("Hello, world") >= 0 ? 0 : EXIT_FAILURE;
}
(0 hat per Definition dieselbe Wirkung wie EXIT_SUCCESS...)
>>Ich kann jetzt hier nichts finden, das ausdrücklich verbietet
>>oder legalisiert, daß ein "fgetc" oder "fread" von einem Signal
>>unter- und abgebrochen werden kann. [...]
> Sie normt das Verhalten nicht und ist somit in dem Bereich völlig nutzlos.
Nur mal so: was sagen die Konkurrenz-Normen (Ada z.B.) in
dem Bereich? Mir fällt nämlich nichts ein, wie man es besser
lösen könnte. Leider. So ist halt ein Signal erstmal eine
"error condition", wie "disk full" oder "I/O error".
Stefan
Rainer Weikusat
> Ich kann jetzt hier nichts finden, das ausdrücklich verbietet
> oder legalisiert, daß ein "fgetc" oder "fread" von einem Signal
> unter- und abgebrochen werden kann.
_Falls man einen eigenen Signal-handler verwendet_.
Das ist |berall genau so dokumentiert und Linux
verhdlt sich auch so.
Das hier fortwdhrend behauptete Gegenteil finde ich bitte wo?
Bernd Eckenfels
> _Falls man einen eigenen Signal-handler verwendet_.
> Das ist |berall genau so dokumentiert und Linux
> verhdlt sich auch so.
Du verwechselst stdio stream funktionen mit low level IO. gets und fegts
liefern s oder null, aber kein EINTR:
Fuer Read hingegen ist es erlaubt:
POSIX allows a read that is interrupted after reading some data
to return -1 (with errno set to EINTR) or to return the number of
bytes already read.
Gruss
Bernd
Rainer Weikusat
> Rainer Weikusat <weik...@students.uni-mainz.de> wrote:
> > _Falls man einen eigenen Signal-handler verwendet_.
> > Das ist |berall genau so dokumentiert und Linux
> > verhdlt sich auch so.
>
> Du verwechselst stdio stream funktionen mit low level IO. gets und fegts
> liefern s oder null, aber kein EINTR:
Nein. f* darf grundsätzlich alles zurückliefern (in errno), was die
'underlying primitives' auch tun, dh EINTR, falls der entsprechende
syscall von einem zurückkehrenden signal handler unterbrochen wurde.
Gibt es keinen sighandler, *dann gibt es auch keine unterbrochenen
syscalls*, weil signals entweder
a) eine 'abnormal exit' verursachen
b) ignoriert werden
Wie sich Xwas-weiß-ich zu diesem Thema äußert, ist mir allerdings
unbekannt. Die Feststellung, das C-Programme nicht auf virtuellen
Maschinen laufen halte ich trotzdem für 'eher unoriginell'.
Jens Hektor
> * Immo 'FaUl' Wehrenberg <im...@faul.dyndns.org> [de.comp.security.misc]:
>> Jens Hektor schrob:
>>>int main ( void ) { write ( 0, "\07", 1 ) ; return 0 ; }
>> -v
> Auf fd 0 rausschreiben ist semantisch nicht 100%ig korrekt, IMO. Aber
> macht nix, 0 ist ja defaultmaessig O_RDWR geoeffnet, und fd 1 und 2 nur
> jeweils ein Duplikat von fd 0. Wie portabel das allerdings ist, sei
> dahingestellt.
Probiers aus. Bisher hat das Programm noch auf jeder Plattform "piep" gemacht.
Nur in ne pipe darf mans nicht stecken.
Rainer Weikusat
> > Ob Du fflush oder fclose machst, ist doch egal, also mache bitte fclose.
>
> Warum?
=> close(2)
Lutz Donnerhacke
>Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>>># 5.2.2 Character display semantics
>
>> Danke. Höchst interessant, wie Unmögliches genormt wird. Nunja. Danke
>> trotzdem.
>
>Besseren Vorschlag? Ich finde es jedenfalls wesentlich
>besser, Zeilenumbrüche derart in Strings zu codieren, als
>wie in Pascal für einen Zeilenumbruch eine extra Funktion
>("Writeln") aufrufen zu müssen.
Extra-Funktion laesst sich gar nicht vermeiden, oder eben einen Eintrag in
einer Stringtabelle, wenn das ueberhaupt ueberall moeglich sein sollte.
>Meinereiner ist C++-verwöhnt, aber in C99 gibt's das
>implizite "return 0" inzwischen auch :)
*seufz* Die Welt ist schlecht.
>> Fehlerbeandlung?
>
>int main() {
> return puts("Hello, world") >= 0 ? 0 : EXIT_FAILURE;
>}
>
>(0 hat per Definition dieselbe Wirkung wie EXIT_SUCCESS...)
*Gna* Wer hat den das verbrochen? Wo ist der Einwand der VMS Lobby?
>Nur mal so: was sagen die Konkurrenz-Normen (Ada z.B.) in
>dem Bereich?
Fehler werfen Exceptions. Normale Signale unterbrechen die Funktionen nicht.
Nebenlaeufigkeit ist Sprachbestandteil und damit auch Interruptbehandlung.
Stefan Reuther
Lutz Donnerhacke <lu...@iks-jena.de> wrote:
> * Stefan Reuther wrote:
>>Lutz Donnerhacke <lu...@iks-jena.de> wrote:
>>>># 5.2.2 Character display semantics
>>[...]
>>Besseren Vorschlag? Ich finde es jedenfalls wesentlich
>>besser, Zeilenumbrüche derart in Strings zu codieren, als
>>wie in Pascal für einen Zeilenumbruch eine extra Funktion
>>("Writeln") aufrufen zu müssen.
> Extra-Funktion laesst sich gar nicht vermeiden, oder eben einen Eintrag in
> einer Stringtabelle, wenn das ueberhaupt ueberall moeglich sein sollte.
Naja, dann fangen "kluge Programmierer" eben an, eine eigene
Ausgabefunktion zu schreiben, die irgendein Steuerzeichen
in "Writeln" umwandelt (`if s[i]=#10 then writeln else write(s[i])'),
weil's Tipparbeit spart und Stringtabellen (man i18n) erst
ermöglicht. Und *dann* hat man ein Portabilitätsproblem, wenn
plötzlich ein Zeichensatz verwendet wird, in dem ein "normales"
Zeichen den Wert #10 hat. Da halte ich es für vorteilhaft, daß
C diesen Teil der Ausgabesemantik spezifiziert.
>>Nur mal so: was sagen die Konkurrenz-Normen (Ada z.B.) in
>>dem Bereich?
> Fehler werfen Exceptions.
Gut so. Wie in C++ :-)
> Normale Signale unterbrechen die Funktionen nicht.
Wird in C halt nicht explizit gefordert oder verboten.
Leider. Für die stdio wäre es eigentlich sinnvoller,
"nicht unterbrechen" zu fordern.
> Nebenlaeufigkeit ist Sprachbestandteil und damit auch Interruptbehandlung.
Mein Problem mit Sprachen, die zu viel definieren (siehe
auch Java) ist, daß sie eben auf gewissen Betrübssystemen
nicht implementierbar sind. Die Programme, die ich momentan
baue, sollen noch auf DOS laufen.
Stefan
Lutz Donnerhacke
Dann wird Dich Ada erfreuen, die Norm ist erstaunlich orthogonal und damit
kurz.
Rainer Weikusat
> >Ich kann jetzt hier nichts finden, das ausdrücklich verbietet
> >oder legalisiert, daß ein "fgetc" oder "fread" von einem Signal
> >unter- und abgebrochen werden kann. Als Fehlerbedingungen gibt
> >es nur EOF und "read error". Ob eine C-Library also nach
> >Signalen automatisch wieder aufsetzt ist ein "Quality of Implementation
> >Issue". Wenn ich nicht will, daß Signale mir meine freads kaputt
> >machen, muß ich halt eine Lib nehmen, bei der das nicht so ist. Gibt's
> >nicht? Schade. Aber was kann die Programmiersprache C dafür?
>
> Sie normt das Verhalten nicht und ist somit in dem Bereich völlig
> nutzlos.
Das ist vermutlich Pech für 'alle diese Leute', die das in C
implementiert haben, was es in Ada nicht gibt. Und auch nicht geben
wird, denn um irgendwohin zu kommen müßte man ja mal anfangen, sich in
eine Richtung zu bewegen und dann wäre man schon wieder so auf
konkretes festgelegt, das geht doch nicht ...
Rainer Weikusat
int nhs_get_char(void)
{
ssize_t nr;
char *pc = cur; /* become register */
if (pc == pnr) {
nr = read(fd, buf, sizeof(buf));
switch (nr) {
case 0:
return -1;
case -1:
nhs_die("nhs_get_char: read: %m");
}
pc = buf;
pnr = pc + nr;
}
cur = pc + 1;
return *pc;
}
"What you see is what you get"
Arnim Weidner
>
> int nhs_get_char(void)
> {
> ssize_t nr;
> char *pc = cur; /* become register */
>
> if (pc == pnr) {
> nr = read(fd, buf, sizeof(buf));
> switch (nr) {
> case 0:
> return -1;
>
> case -1:
> nhs_die("nhs_get_char: read: %m");
> }
>
> pc = buf;
> pnr = pc + nr;
> }
>
> cur = pc + 1;
> return *pc;
> }
>
> "What you see is what you get"
Hallo,
Das hat mich schon im Stevens gewundert, was man bei einem solchen
Fragment macht, wenn man fd[] hat. Also wie realisierst Du ein
gleichzeitiges Lesen aus zwei Dateien bei dieser Funktion?
Arnim
Mark-Oliver Wolter
> while ((c = fgetc (stdin)) != '\n' && c != EOF)
Die Schönheit von c-code. Wuäh.
Immo 'FaUl' Wehrenberg
> Immo 'FaUl' Wehrenberg <im...@faul.dyndns.org> wrote:
>> while ((c = fgetc (stdin)) != '\n' && c != EOF)
> Die Schönheit von c-code. Wuäh.
?
FaUl
end
This article does not support incompatible and broken newsreaders.
--
"Manche Benutzer haben immer Viren und manche Benutzer haben nie
Viren." (Detlef Bosau)