Hallo Bernd, * Bernd Schmelter [23.07.02 20:48]:

hmmm, das lese ich anders.

http://www.rfc-editor.org/rfc/rfc2822.txt

Allerdings ist die M.-ID optional, aber wenn, dann eindeutig. Von fqdn steht da nix, wird aber imho gerne genommen wegen "eindeutig".

Die M-ID von Evolution sollte demnach nicht falsch sein.(?)

In rfc1036 habe ich folgendes gefunden: ,----[ rfc1036 ]- | | 2.1.5. Message-ID | | The "Message-ID" line gives the message a unique identifier. The | Message-ID may not be reused during the lifetime of any previous | message with the same Message-ID. (It is recommended that no | Message-ID be reused for at least two years.) Message-ID's have the | syntax: | | "> | | In order to conform to RFC-822, the Message-ID must have the format: | | | | where full_domain_name is the full name of the host at which the | message entered the network, including a domain that host is in, and | unique is any string of printing ASCII characters, not including "<" | (left angle bracket), ">" (right angle bracket), or "@" (at sign). | `---- Gruss, Andreas -- " Schlechte Zeugen sind Augen und Ohren fuer Menschen, wenn sie Barbarenseelen haben " [Heraklit]

Hallo Frank, * Frank Rasche [23.07.02 22:29]:

Andreas Kneib schrieb am Dienstag, 23. Juli 2002 um 21:19:

...

In rfc1036 habe ich folgendes gefunden:

Stimmt, aber das ist die RFC für:

"Standard for Interchange of USENET Messages"

Stimmt, Du hast recht. Ich Torfkopp hab' wohl mal wieder zu lang gedacht und zu kurz geschaut. RFC1036 findet ja in Rattis Fall gar keine Anwendung...

Ich denke schon, dass es ein Fehler (?) von Evolution ist und der SMTP-Server den domain-name daher nicht korrekt ersetzt. Immerhin ist das wohl bei allen Evolution-Usern hier in der ML so.

Mal sehen, was die Mailbox unserer Liste zum Thema Evolution und Message-ID sagt: $ grepmail "X-Mailer: Ximian Evolution" ~/Mail/linux-suse | grep Message-Id: (Doubletten rausgeschnitten) Message-Id: <1027201741.1368.67.camel@ratti> Message-Id: <1027229469.15328.2.camel@linux> Message-Id: <1027253156.16647.14.camel@mhcln01> Message-Id: <1027269817.8261.1.camel@mhcln02> Message-Id: <1027273088.9849.29103.camel@mccallum> Message-Id: <1027308769.1260.16.camel@server> Message-Id: <1027370423.5353.27.camel@AMD-800> Message-Id: <1027418234.1492.17.camel@mrichte> Message-Id: <1027412216.1970.25.camel@tk226> Message-Id: <1027412294.6166.16.camel@discovery> Message-Id: <1027419637.2641.22.camel@schmedes> Message-Id: <1027422181.9066.5.camel@bevok1> Die Ausbeute an FQDN sieht ja mager aus... :-(

Lt. RFC würde ich die erzeugte Message-Id auch nicht unbedingt für falsch halten, aber naja... besser wäre es schon, wenn sich Evolution genauer an die RFCs halten würde.

ACK!

Hab trotzdem keine Lösung dafür, wie man das bei Evolution abstellen kann. Sorry ;-)

I rm -rf $(locate evolution) II rpm -ihv mutt-1.4-1.rpm III ,------[ .mutt/muttrc ] | set hostname="fqdn.xy" `------* ;-)

Wäre aber interessant zu wissen, ob das Suse-spezifisch, bzw "deutsch"-spezifisch ist.

Das wuerde mich allerdings auch interessieren. Gruss, Andreas -- Es gibt eine Sorte ungemein ueberlegener Menschen, die gern versichern, alles sei relativ. Das ist natuerlich Unsinn, denn wenn _alles_ relativ waere, gaebe es nichts, wozu es relativ sein koennte. [Russell]

Hallo, On Tue, 23 Jul 2002, Frank Rasche wrote: [..]

Hab mal ein bisschen gegooglet und dies ist zumindest kein "nur-deutsch"-Problem, da das Phänomen auch auf einer italienischen und spanischen Linux-Liste auftritt. (nein, ich kann weder italienisch noch spanisch ;-))

Erschreckend oft hab ich aber "...camel@localhost" oder "...camel@localhost.localdomain" (hoppla, das ist ja fast ein fqdn ;-)) gefunden.

Ist ja irgendwie nicht so optimal...

In der Ximian-Buglist steht aber nix dergleichen drin :-(

Evolution/Ximian machen's sich da eindeutig zu einfach. Das Ergebnis von gethostname/gethostbyname nichtmal rudimentaer zu testen halte ich schonmal fuer leichtsinnig (ich sach nur "@linux.local" oder schlicht "@foo"). Was mich aber aergert, ist dass es anscheinend keine Moeglichkeit gibt Evolution das Erzeugen einer M-Id abzugewoehnen (denn dann wuerde der erste SMTP, der eine korrekte M-Id erzeugen kann, eben dieses machen, was eine vollkommen korrekte Vorgehensweise waere). Evtl. hilft mein in meiner anderen Mail erwaehnte Ansatz. Oder eben rpm -e evolution; rpm -i mutt :)) -dnh -- 129: Knigge Kofler des erfolgreichen Kommunizierens (Heinrich Konrad Bartels)

Hallo Frank, * Frank Rasche [24.07.02 11:26]:

Kann denn z.B. ein anderer Newsreader einen richtigen FQDN erzeugen oder benutzt der auch den frisierten Hostnamen?

Slrn kann's: ,----[ .slrnrc ]- | | % Die Message-ID soll mit "andreas.kneib.biz" generiert werden | set generate_message_id 1 | posting_host andreas.kneib.biz | `---- Und Gnus kann's vermutlich auch. ;-) Gruss, Andreas -- who | grep -i blonde | talk; cd ~; wine; talk; touch; unzip; touch; strip; gasp; finger; gasp; mount; fsck; more; yes; gasp; umount; make clean; sleep -- Stefan Schumacher in d.c.o.u.bsd

Hallo, On Wed, 24 Jul 2002, Frank Rasche wrote:

Also sprach David Haller am 24.07.2002:

...

Evolution/Ximian machen's sich da eindeutig zu einfach. Das Ergebnis von gethostname/gethostbyname nichtmal rudimentaer zu testen halte ich schonmal fuer leichtsinnig (ich sach nur "@linux.local" oder schlicht "@foo").

Allerdings! Je nach HOSTS-Datei kommen dann ja auch solche Sachen wie "@localhost" etc. raus.

Jup. Aber den fqdn als erstes nach der IP scheint zu funktionieren.

...

Was mich aber aergert, ist dass es anscheinend keine Moeglichkeit gibt Evolution das Erzeugen einer M-Id abzugewoehnen (denn dann wuerde der erste SMTP, der eine korrekte M-Id erzeugen kann, eben dieses machen, was eine vollkommen korrekte Vorgehensweise waere).

ACK!

Eben *seufz*

...

Evtl. hilft mein in meiner anderen Mail erwaehnte Ansatz.

Jau, genial einfach... :-) Aber schon hart, wenn man an der Namensauflösung rumdrehen muss dafür. Würde auch nicht ausschliessen, dass das eventuell mit anderer Software auch zu Problemen führt.

*hehe* das kann ich im Moment nichtmal sagen, ich tausch hier jedesmal beim on- bzw. offline-gehen die /etc/hosts aus (gegen ne /etc/hosts.online bzw. /etc/hosts.offline ;) die 127.0.0.1-Zeile ist aber in beiden gleich.

Kann denn z.B. ein anderer Newsreader einen richtigen FQDN erzeugen oder benutzt der auch den frisierten Hostnamen?

Naja, tin (definitiv) und slrn und gnus (kann mir nicht vorstellen dass nicht) koennen das.

...

Oder eben rpm -e evolution; rpm -i mutt :))

;-)

Ebent *eg*. Und IMO sind mutt/tin/slrn/gnus deutlich effektiver zu verwenden... Bleibt nur noch der Kram wg. M$ Exchange, PIM und so, den Evolution wohl kann...

btw: Die Empfehlung des RFC2822 die Zusammensetzung der Msg-ID folgendermassen zu realisieren: < timestamp+PID @ FQDN> würde IMHO reichen um "unique" zu garantieren.

Naja, praktisch wohl schon, theoretisch nur bedingt... Der "unique"-Teil ist aber, wie man ja u.a. hier sieht, nicht das Problem, sondern der Rest (also 'username@host.domain.tld' oder direkt '@host.domain.tld').

Die Wahrscheinlichkeit, dass sie sich nicht unique ist, wäre ja wohl praktisch null. (Besonders wenn der SMTP sie generieren würde)

Noe. Das waere definitiv signifikant ungleich null! Es lassen sich nur $NUM einzigartige Msg-Ids/sekunde erzeugen... Aber im Vergleich irrelevant. *seufz* Schliesslich gibt's nur beschraenkt PIDs (per default auf SuSE z.B. 32k), und faelschen lassen die sich auch recht einfach... In der Praxis reicht's aber wohl in mind. 99.9% der Faelle. Die meisten anstaendigen MUAs (und MTAs) verwenden aber noch ein zusaetzliches zufaelliges Element[1], das dann eine Einzigartigkeit garantiert, die fuer diese Anwendung mehr als ausreicht. Wie gesagt: das ist nicht das Problem, sondern der "host-part", also das nach dem '@'...

Also auch in diesem Punkt würde ich Jeff widersprechen.

Jep. -dnh [1] Im einfachsten Fall z.B. ein Zeichen aus /dev/[u]random o.ae. ;) --

Du beschreibst einen DAE. (Dümmster Anzunemender Elch) Dau ist Dau bleibt Dau und wird nicht wieder Elch. Elch ist Elch und will nicht dau werden und wird manchesmal Trolleclh. [H. Stowasser und Woko° in dag°]

Hallo Frank, * Frank Rasche [23.07.02 23:56]:

Hab mal ein bisschen gegooglet und dies ist zumindest kein "nur-deutsch"-Problem, da das Phänomen auch auf einer italienischen und spanischen Linux-Liste auftritt. (nein, ich kann weder italienisch noch spanisch ;-))

Erschreckend oft hab ich aber "...camel@localhost" oder "...camel@localhost.localdomain" (hoppla, das ist ja fast ein fqdn ;-)) gefunden.

Ist ja irgendwie nicht so optimal...

In der Ximian-Buglist steht aber nix dergleichen drin :-(

Die Evolutionaeren von Ximian gehen die Geschichte fuer meinen Geschmack etwas zu billig an. Wie es Bernd schon sagte: Die Message-ID ist optional, aber wenn, dann eindeutig, was bei camel@localhost wohl eher nicht der Fall ist. Also sollte der Nutzer zumindest die Moeglichkeit haben, auf eine Message-ID verzichten zu koennen, wenn er schon keine nach seinem Willen generieren kann. Und das durch eine Option in Evolution, und nicht dadurch, dass er von seinem lokalen MTA die Message-ID herausschneiden laesst. Das Verhalten von Evolution ist in meinen Augen weniger fehler- als mangelhaft. Gruss, Andreas -- begin at the beginning, the King said gravely, and go on till you come to the end: then stop. [Lewis Carroll: Alice's Adventures in Wonderland]

Hallo, On Wed, 24 Jul 2002, Jörg Roßdeutscher wrote:

David Haller:

...

Das ist aber schon in aelteren RfCs festgelegt, aber selbst 2822...

==== Though optional, every message SHOULD have a "Message-ID:" field. [..] The "Message-ID:" field contains a single unique message identifier. [..] The uniqueness of the message identifier is guaranteed by the host that generates it (see below). ====

...sagt's IMO eindeutig.

Ja, verstehe ich auch so:

Ich SOLLTE eine MessageID erzeugen. Ich MUSS nicht. Aber wer auch immer eine erzeugt, MUSS eine eindeutige ID erzeugen.

Exakt. Wenn keine erzeugt wird, dann ist genau das dann die Aufgabe des ersten MTAs der eine eindeutige erzeugen kann ;) Und Mails, die von aussen kommend keine MID haben sind wohl i.a.R. spam.

Sprich: Sie lassens, oder sie machen es richtig. Aber nix halbes.

Genau. Das mindeste ware, dass man a) die Erzeugung der MIDs abschalten kann und b) den hostnamen auch per Hand einstellen kann wenn die das nicht anbieten ist das ein Armutszeugnis. Mein Gottchen, so eine Checkbox mehr wird sich in den Optionen wohl unterbringen lassen, zur Not mit ner globalen Variable im Hintergrund und dann noch die Erzeugung mit 'if(generate_message_id) { /* */ }' kapseln... Das kann ja nicht so schwer sein...

...

Die Loesung waere, dass du an deinem hostnamen schraubst. Ich hab's uebrigens auch so. Nenn deinen Host eben 'ratti.gesindel.de', dann sollt's auch mit evolution klappen, denn o.g. 2 funktionen liefern bei mir:

Der Tip ist inhaltlich gut.

Ich wäre aber nicht bereit, meinen Rechner mit einem Internetgültigen Namen zu betreiben, nur weil ein paar Leute nicht in der Lage sind, so ein wirklich billiges Problem anzugehen. [..]

Wieso? Wenn du das _nur_ in die /etc/hosts eintraegst (und da eben mit der 127.0.0.1 IP, dann juckt das auch _nur_ deinen Rechner, das ist quasi ein alias fuer 'localhost'. Da kannst du reinschreiben was du willst. 'slarty.dhaller.de' gibt's ja auch nur hier auf localhost, via DNS findest du den genauso "gut", wie du mittels 'localhost' an meine Kiste herankommst, nur dass du mit 'localhost' keine Fehlermeldung bekommst ;) Solange du einen domain-weit eindeutigen hostnamen verwendest muesste alles klappen.

daß ich nciht plötzlich den falschen Server bombadiere oder dergleichen. Wir sind hier mit mehreren im Netz, unter anderem Windows-Clients, mit eigenem DNS. Ne, keine Böcke auf sowas. ;-)

Wuesste nicht, wie die was von deiner hosts mitbekommen sollten. Wenn du nen Nameserver auf der Kiste laufen hast, da weiss ich jetzt nicht genau, wie das ablaeuft, ich wuerde aber tippen, dass es genauso geht, da die IP 127.0.0.1 ja _immer_ localhost ist... Probier's doch einfach mal... -dnh PS: Ich geh davon aus, dass du Evolution nicht deswegen nutzt, dass es so ein toller MUA ist... *scnr* -- Debating unix flavors in the context of anything Microsoft is like talking about which ice cream flavor tastes least like sawdust with turpentine sauce. -- stolen from Joe Zeff's sig

Jörg Roßdeutscher wrote:

Moin,

Jörg Roßdeutscher:

[...]

...

PS: Ich geh davon aus, dass du Evolution nicht deswegen nutzt, dass es so ein toller MUA ist... *scnr*

Ne, wegen des Grammatik. *scnrt* ;-))

Ich bin begeitert von der Oberfläche und den Filtern.

Ich war davon begeistert und auch von der Geschwindigkeit. Aber in kleinen Details - hier das Beispiel Message-ID - erinnert mich das langsam ( zugegeben, etwas übertrieben) an das Original. Kann man da nun endlich den Zeilenumbruch einstellen? MfG Benn -- #250319 - http://counter.li.org

On Fri, 26 Jul 2002 at 00:09 (+0200), Ratti wrote:

Bernd Schmelter:

...

Kann man da nun endlich den Zeilenumbruch einstellen?

:-))))

Man kann nach wie vor in Evolution exakt fünf(5!) Dinge konfigurieren:

- HTML-Mails oder Plain Text? - Bei leerem Betreff: Fragen? - Wenn ausschließlich BCC-Empfänger: Fragen? - HTML-Mail an nicht-HTML-Kontakt: Fragen?

- Weiterleitung als [ Anlage | Text | Umgeschrieben ]

Das brauch jetzt keiner kommentieren. Ich werde ihm nicht widersprechen. Er hat recht. Ersparen wir der Liste den Traffic.

Hast Du nicht vorher behauptet, dass Evolution _gar_ keine Optionen hat? Wenn es diese fünf Optionen gibt, könnte man doch in diesen Dialog noch ein paar hinzufügen, z. B. Message-ID und Zeilenumbruch. Ich persönlich bin aber der Meinung, dass man bei so einem Konzept wie es Ximian verfolgt gar keine Option einbauen sollte. Der MUA generiert schlicht keine Message-ID und fertig. Damit wäre allen geholfen. Was anderes ist das bei Programmen wie Mutt, wo man sowieso alles konfigurieren kann. Da kommt's auf die eine Option mehr oder weniger auch nicht an. Gruß, Bernhard -- _________ http://www.bwalle.de _________________________________________________ Es kann passieren, was will: Es gibt immer einen, der es kommen sah. -- Fernandel

Hallo Ratti, Frank, On Fri, 26 Jul 2002, Frank Rasche wrote:

Jörg Roßdeutscher schrieb am Donnerstag, 25. Juli 2002 um 21:27:

...

[ David Haller schrieb: ]

...

Genau. Das mindeste ware, dass man a) die Erzeugung der MIDs abschalten kann und b) den hostnamen auch per Hand einstellen kann

wenn die das nicht anbieten ist das ein Armutszeugnis. Mein Gottchen, so eine Checkbox mehr wird sich in den Optionen wohl unterbringen lassen,

...

Ähm... Evolution hat keine Optionen. Du kannst dort nichts einstellen.

*ARGL* Was ein Armutszeugnis!

Ich habe mir mal die Sourcen von 1.0.8 angeschaut. Die Funktion, die die Message-ID generiert ist recht simpel und fragt lediglich gethostname() ab. (Wen es interessiert: Message-ID: int time (NULL).getpid().int counter.camel@hostname)

Und das ist schonmal faslch. gethostname(2) gibt den hostnamen aus, _nicht_ den FQDN! Aber das zu programmieren war den Evolution Leuten wohl zu schwierig (*muahahaha* [1]). Das, was dazu noetig waere, ist in 10 min. programmiert -- selbst wenn man 'gethostbyname(3)' noch nicht kannte... Bis auf die Fehlerbehandlung ist's grad mal: ==== char * hostname; char s[BUFSIZ]; struct hostent * h; if(gethostname(s, BUFSIZ) == 0) { if( (h = gethostbyname(s)) != NULL) { hostname = h->h_name; } else { /* Fehlerbehandlung */ } } else { /* Fehlerbehandlung */ } ==== und schon hat man 'hostname -f' quasi nachprogrammiert ;)

Also wie David schon sagte, wäre es kein grosses Problem da noch ne Abfrage reinzubasteln oder den Hostnamen selbst zu bestimmen (wenn es denn sowas wie "Optionen" gäbe). Ich schau bei Gelegenheit mal, ob man den Message-Id-Header nicht einfach raushauen kann.

Das waere wohl das einfachste... Oder du baust obiges Fragment statt dem jetztigen 'hostname = gethostname(/* */)' ein (so in etwa). Ich kenn den Evolution-code nicht und will's auch nicht[2] ;)

Mittlerweile denke ich, dass eine Änderung von /etc/hosts auch nur bedingt von Nutzen ist. In meinem LAN habe ich IPs von 192.168.. Da bringt ein Schrauben an 127.0.0.1 keine Änderung, was den Hostnamen angeht.

Doch. Genau das ermoeglicht das! $ ./gethostname slarty $ ./gethostbyname `./gethostname` hostname: 'slarty.dhaller.de' aliases 0: 'slarty' aliases 1: 'localhost' aliases 2: 'news.slarty.dhaller.de' aliases 3: 'news' addr 0: '127.0.0.1' (obige Proggies sind simple Wrapper (s.o. u. [3]) um die jew. Funktionen). $ hostname slarty $ hostname -f slarty.dhaller.de $ grep localhost /etc/hosts 127.0.0.1 slarty.dhaller.de slarty localhost news.slarty.dhaller.de news Mangels Nameserver kann ich das Verhalten damit leider nicht testen.

Ich müsste also mein gesamtes Netzwerk umstellen :-(

Noe. Wieso auch? Die Kiste ist localhost/127.*. Daran aendert auch ein zusaetzlicher Name nix. Und das stoert auch den Rest nicht! Man sollte halt keinen Namen verwenden, der nicht auf die eigene Kiste zeigen soll ;)

...

Außerdem bin ich da trotzig. Eher wechsel ich den MUA. Ich bin nicht unter erheblichen Mühen auf dieses OS gewechselt, um mich schon wieder verPIEPen zu lassen. Ximian soll eine vernünftige oder keine MsgID generieren wie es sich gehört. Punkt.

*lob* ratti: Ueberleg halt nochmal weswegen genau du Evolution willst/brauchst/magst. AFAIK hat Evolution halt ein paar Features (Abgleich mit M$exchange?) die kein(?) anderes Programm fuer Linux bisher mitbringt... Falls du aber nur einen MUA brauchst, dann nimm Mutt oder meinetwegen, wenn's unbedingt ne GUI sein muss auch KMail... (bei mutt kannst du dann so viel einstellen dass du dich beim "ersten Kontakt"[tm] wohl erstmal ueberfordert fuehlst *eg*, aber sich da einmal durchzuwuehlen (anhand des Defaults/von Vorlagen[4] und ggfs. mit Hilfe) lohnt sich -- fuer jemand, der ungern von einer Software bevormundet wird (wie man's anscheinend von Evolution wird) also genau das richtige) *g*

Hau das doch einfach in die Bugliste.

Das ischa (angeblich, lt. ximian) kein Bug... -dnh [1] ich lass Anspielungen bzgl. (der) "Evolution" mal weg... [2] naja, zur Not liesse ich mich wohl breitschlagen, waere ja nicht das erste Mal, das ich nen MUA patche... [3] nur mit nem "main" und ein bisschen Ausgabe drumrum, bei Interesse kann ich die gerne mailen, sind nur 276 bzw. 765 Bytes ;) [4] von uns oder auch per "Konfigurator" erstellt (ich hoffe den gibt's noch online: ==== ~/.muttrc ==== ## Erzeugt von: Mutt-Konfigurator, 1999 Bjørn Bürger (b.buerger@gmx.de) ## http://www.lk.etc.tu-bs.de/lug/faq/mutt_config.php3 ==== Der ist leider aber veraltet (fuer mutt-0.96!) liefert aber immer noch ne gute Grundkonfig und das auf Deutsch, das ein oder andere Keyword musst du dann halt aendern/rausschmeissen). Bei mir sind dann diverse Details von Sebastian Helms' Config und die anderer eingeflossen und man aendert eigentlich immer wieder mal das ein oder andere :) -- Thou shalt not droppeth thy leatherman onto live motherboards. -- Andreas "Buzh" Skau

Frank Rasche:

(Google nach "camel@localhost": ungefähr 3,520 Resultate)

Schönes Argument! Danke!

Ich habe mir mal die Sourcen von 1.0.8 angeschaut. Die Funktion, die die Message-ID generiert ist recht simpel und fragt lediglich gethostname() ab. (Wen es interessiert: Message-ID: int time (NULL).getpid().int counter.camel@hostname)

Meine C-Kenntnisse beschränken sich auf "Hello World" unter Verletzung sämtlicher Standards. Wärest du oder jemand anders vielleicht in der Lage, einen Patch zu erstellen mit der Zielsetzung, keine ID zu generieren? Mein Evolution ist selbstgedreht, könnte ich also anwenden. Gruß, Ratti -- http://www.gesindel.de/neu/ | Fontlinge | Die Schriftenverwaltung für LINUX

Moin, * Jörg Roßdeutscher [02-07-26 23:01]:

Ihr könnt mich ja bashen, dann stimmts.

EY, DU DUMPFBACKE, KANNSTE MAL AUFHÖR'N, SO'NE FALSCHE ID ZU SETZEN??? (Gut so?) Thorsten -- He who receives an idea from me, receives instruction himself without lessening mine; as he who lights his taper at mine, receives light without darkening me. - Thomas Jefferson

Hallo, On Sat, 27 Jul 2002, ratti wrote:

ratti:

...

...

Ihr könnt mich ja bashen, dann stimmts. Thorsten Haude: [hat ein bisschen (harmlos) "rumgebasht" -- Thorsten: mehr als ein Alibi war das ja nicht, ich weiss doch, dass du das besser kannst!] Danke, das hab ich gebraucht. :-)

Oh, ihr poesen Purschen Ihr! Kommt zu Papa! Alle beide! So wird das ja nix. *patsch* *patsch*

Kommen wir zu einen unangenehmen Thema.

Ich habe hier die finalen Antworten. Ich erspare euch den Fullquote und zitiere relevante Teile:

[*arg* was/wo soll ich da kuerzen??? Ich setz mal meinen geliebten xemacs drauf an und schau, ob's zumindest die ein oder andere Zeile bringt ;)]

# -------------------------------------------

...

I think it's expressed very clear. You don't have to generate an id. (See previous mails) But if you do so, it must be globally unique. globally unique to the application.

{ Hahahahaha!! "Globaly unique" innerhalb meiner Applikation!! Aua!!! Das ist Politiktauglich! }

____ ____ ____ ____ ____ _ | _ \| _ \| _ \| _ \| _ \| |_/\__ Ack! *GrrrrrrrrRRRRRRRRRRRRRRRRRR| |_) | |_) | |_) | |_) | |_) | \ / | _ <| _ <| _ <| _ <| _ <|_/_ _\ |_| \_\_| \_\_| \_\_| \_\_| \_(_) \/

[...]

...

But it's not a big thing. All we need is a little button: [ ] Generate MsgID hell no. [...] give it up, you are just plain wrong. you have no idea what the hell you are talking about. Please stop wasting our time. Jeff # -------------------------------------------

Ratti? Darf ich? Darf ich? Darf ich? Darf ich? Kannst du mir das "offiziell" forwarden? Ich bekomm Lust diesem "jeff"-"coola-hacka"-Kerl nicht nur das ein oder andere RfC um die Ohren zu hauen, der ist ja nicht nur ignorant sondern glatt lernresistent! -- und lesen kann er offenbar auch nicht... *machschonmachdasfwdenkerlwillichbashenbashenbashen* Ich weiss auch schon die Anrede: "Hey stupid, Should I spell it out for you, repeating my colleague? Can you read english? At all? Yes? Really? Are you sure? Fine! Read then! Read the $DEITYdamn fucking RfC! It's all there, in print, in english, just as if specifically for you! " Ne echt. Spaetestens jetzt ist Evolution (und Ximian) fuer mich gestorben[1]. Wenn 'Jeffrey' wenigstens z.B. ne gute Entschuldigung haette wg. "nicht Muttersprache" oder so... Aber so??? [..] "plain wrong" und "you have no idea"??? "No boy, the one who's plain wrong and who has obviously NOT A FUCKING IDEA what he's talking about, that, my pal, IS YOU!! READ THE F*CKING RfC!!! It's obvious, that you a) cannot read the RfC for yourself b) don't even understand the relevant phrases being cited at you, even dumbed down And I'm sick and tired of rereading it to you again and again... " [..] "wasting our time" (???) "Uh, sure... I bet! Keepin' ya from playin' whutever's "eleet" with ya dickheads right now, eh? " (ja, ich bin SAUER[2], merkt man das? Und ja, ich hab mich sogar noch zurueckgehalten, da das hier OT ist...)

Das hätte man auch kürzer sagen können: "Please don't use evolution anymore. It's not intended as a mailingprogramm, we're just riding around a little bit on our C-Compilers to find out how to break the rules."

Yes, sir. Nice outlooks. ^^^^^^^ Scheint so *grumpf* *ARGL*

"Good day, and may you rot in hell (or whatever your religion has in store for utter morons like you). " (du weisst ja: ich empfehle 'mutt'. Das hat eh keine Bugs. :) ==== mutt(1) ==== BUGS None. Mutts have fleas, not bugs ====

End of Topic.

"whishful thinker"...

Gruß, Ratti, Ruhepuls 200.

Mein Beileid! -dnh, Ruhepuls k.A., wohl irgendwo zw. 60 und 100; der im Moment aber wohl ueberschritten wird *grrrr* [1] eigentlich schade, wenn sich Vorurteile so bestaetigen... [2] und man moege mir das Englisch verzeihen... --

Es ist nicht schlimm wenn du es nicht verstehst. Schliesslich darf man nicht allzugrosse Ansprüche an dag Leser stellen. [Woko° in dag°]

Moin, * Jörg Roßdeutscher [02-07-27 18:01]:

Heute Abend geh ich zum Türken an der Ecke, hole mir 5 große Dosen Astra und guck mir mutt an.

Genau, das ist auch nur im Suff zu ertragen. Thorsten -- Der Leser hat's gut: Er kann sich seine Schriftsteller aussuchen. - Kurt Tucholsky

On Sat, 27 Jul 2002 at 11:45 (+0200), Ratti wrote:

Jörg Roßdeutscher:

...

...

Ihr könnt mich ja bashen, dann stimmts.

Thorsten Haude:

...

EY, DU DUMPFBACKE, KANNSTE MAL AUFHÖR'N, SO'NE FALSCHE ID ZU SETZEN???

(Gut so?)

Thorsten

Danke, das hab ich gebraucht. :-)

Kommen wir zu einen unangenehmen Thema.

Ich habe hier die finalen Antworten. Ich erspare euch den Fullquote und zitiere relevante Teile:

# -------------------------------------------

...

I think it's expressed very clear. You don't have to generate an id. (See previous mails) But if you do so, it must be globally unique.

globally unique to the application.

{ Hahahahaha!! "Globaly unique" innerhalb meiner Applikation!! Aua!!! Das ist Politiktauglich! }

*g* Das ist wirklich gut. Anscheinend hat er gerade ein Buch über C gelesen und was von globalen Variablen gehört, die ja nur innerhalb der Anwendung existieren. So einen Mist habe ich schon lange nicht mehr gehört. Wäre fast reif für eine Signatur.

[...]

...

But it's not a big thing. All we need is a little button: [ ] Generate MsgID

hell no.

[...]

give it up, you are just plain wrong. you have no idea what the hell you are talking about. Please stop wasting our time.

Jeff # -------------------------------------------

Eigentlich sollte man sich mal bei seinem Vorgesetzten beschweren. Dieser Ton ist meiner Meinung nach, wenn man eine offizielle Ximian-Signatur benutzt, nicht gerechtfertigt. Selbst dann nicht, wenn Du wirklich falsch liegen würdest. Immerhin wollen die ihr Zeug (d. h. ihre Erweiterungen) verkaufen und springen mit potentiellen Kunden so um!

Das hätte man auch kürzer sagen können: "Please don't use evolution anymore. It's not intended as a mailingprogramm, we're just riding around a little bit on our C-Compilers to find out how to break the rules."

*g* Diese Ignoranz erinnert mich eigentlich nur an Microsoft. Kein Wunder, schließlich ist Evolution auch ein Outlook-Klon. *eg* Gruß, Bernhard -- _________ http://www.bwalle.de _________________________________________________ Mit nichts ist man freigebieger als mit gutem Rat. -- Francois Duc de La Rochefoucauld

Moin, Ratti:

...

globally unique to the application.

Andreas Kneib:

Nun denn.... :-)

Welche Message-ID traegt Jeffrey Stedfast eigentlich so in seinen Mails mit sich herum?

Das ist eine sehr gute Frage. Wieso bin ich da nicht drauf gekommen? Let's have a look... Oooooh: Message-Id: <1027373387.2563.4.camel@tazmanian-devil.boston.ximian.com> Was sehe ich da? Ein FQDN? Klar, schliesslich will er keinen Ärger. ;-) Bye, Ratti -- http://www.gesindel.de/neu/ | Fontlinge | Die Schriftenverwaltung für LINUX

Hallo, On Fri, 26 Jul 2002, Jörg Roßdeutscher wrote:

es war aber auch mal wieder Zeit, mit jemandem Streit anzufangen.

*heh* [Jeffrey Stedfast:]

[Jörg Roßdeutscher:]

...

I'd like to continue using this program. I really like it. But I get bashed on my mailinglists. It seems many people are checking this, I get a mail every month: "Correct your MsgID!". Hm, maybe typical german. :-)

sounds like someone who has no idea what he is talking about and wants to feel all 31337 to me.

... look who's talking ... [s.u. die '^']

besides, the CVS versions of Evolution resolve the local hostname to use the FQDN, so your make-believe problem should be gone.

Oh, sie haben gethostbyname entdeckt! *eg*

Jeffrey Stedfast Evolution Hacker - Ximian, Inc. ^^^^^^

------------------------------------------------------------------------ Jörg Roßdeutscher:

...

...

...it has to be unique. And other programs do it that way.

Jeffrey Stedfast:

...

Please read further and note that unique means only unique to that particular machine that generates it. [..] I think it's expressed very clear. You don't have to generate an id. (See previous mails) But if you do so, it must be globally unique.

Tja, dem gibst du die passende Antwort :) *Applaus* -dnh, sich grad mal das Ding saugen und sich mental schonmal auf den code vorbereitend... *g* PS: IMO solltest du trotzdem mal das mit der hosts und der Zeile 127.0.0.1 ratti.gesindel.de localhost ratti ausprobieren (da gethostbyname/'hostname -f' schon den richtigen FQDN liefern sollte... -- The Universe -- some information to help you live in it. 2 IMPORTS: None.

On Sam, 27 Jul 2002 at 07:16 (+0200), David Haller wrote: [...]

static int count = 0; int hrv; char *ret; + char * use_fqdn;

hrv = gethostname (host, sizeof (host)); + + if( hrv == 0 && ! ( (use_fqdn = getenv("EVOLUTION_MSGID_FQDN")) != NULL + && strncmp(use_fqdn, "no\0", 3) == 0) ) { [...]

Nur mal so am Rande: Welchen Sinn hat es hier, strncmp() statt schlicht strcmp(use_fqdn, "no") zu nutzen? strncmp() vergleicht auch nur _höchstens_ 3 Byte, maximal aber bis zum ersten Null-Byte. In welchem Fall also sollte sich hier strncmp anders verhalten als strcmp? Jan

* Thorsten Haude schrieb am 28.Jul.2002:

* Jan Trippler [02-07-28 21:26]:

...

Nur mal so am Rande: Welchen Sinn hat es hier, strncmp() statt schlicht strcmp(use_fqdn, "no") zu nutzen? strncmp() vergleicht auch nur _höchstens_ 3 Byte, maximal aber bis zum ersten Null-Byte. In welchem Fall also sollte sich hier strncmp anders verhalten als strcmp?

Laut dem C:ARM vergleicht strcmp() bis zum ersten Unterschied. Es wird erwähnt, daß die Strings Null-terminiert sein sollen, aber nicht explizit, daß er bei der \0 aufhört, zu vergleichen.

Bei \0 hört der Vergleich auf.

Außerdem spart das strncmp() jeden weiteren Gedanken über das Thema und ist darum per se besser.

Unsinn. Wenn Du nicht weißt, wie lang ein String ist, ist es immer besser, Du vergleichst bis zum Ende. Bernd -- Was ist quoten? Quoten ist das Zitieren aus einer mail, der man antwortet. Und wie macht man es richtig? Zitate werden mit "> " gekennzeichnet. Nicht mehr als nötig zitieren. Vor den Abschnitten das Zitat, auf das man sich bezieht, mit einer Zeile Abstand oben und unten. |Zufallssignatur 12

On Fre, 02 Aug 2002 at 20:46 (+0200), Thorsten Haude wrote:

* Bernd Brodesser [02-07-29 11:08]: [str(n)cmp]

...

Bei \0 hört der Vergleich auf.

Das ist die Vermutung. Da sich nichtmal das C:ARM (0-13-326224-3) dazu eindeutig äußert, fände ich einen Beleg hilfreich.

Manno, dann probiers doch aus! Ein String wird in C _immer_ nullterminiert! Es gibt keine Ausnahmen, ein String ist bei 0 zu Ende. Zeige mir _ein_ Beispiel, in dem das nicht so ist. Wenn strcmp() nicht bei Null aufhören würde, müsste folgender Vergleich einen Wert ungleich Null liefern: <schnipp> #include int main (int argc, char *argv[]) { char s1[512], s2[256]; memset (s1, 0, sizeof s1); memset (s2, 0, sizeof s2); *(s1 + 128) = 1; *(s2 + 128) = 2; return (strcmp (s1, s2)); } <schnapp> Bernds Aussage ist keine Vermutung, sondern Tatsache. Hol Dir die Sourcen, schau nach, baue Testprogramme, ...

...

...

Außerdem spart das strncmp() jeden weiteren Gedanken über das Thema und ist darum per se besser.

Unsinn. Wenn Du nicht weißt, wie lang ein String ist, ist es immer besser, Du vergleichst bis zum Ende.

Es sei denn, Du hast weniger als beliebig viel Speicher.

Hä? Das verstehe wer will. Den Speicher braucht Du, wenn Du die Strings deklarierst - unabhängig davon, was Du anschließend mit ihnen machst. Wieso soll ein Vergleich via strcmp mehr Speicher brauchen als strncmp? Jan P.S.: Du stellst einen Sachverhalt in Frage, der die Grundlage für das gesamte Stringhandling in C bildet. Ich weiss nicht, was C:ARM ist, aber schau mal in *Programmieren in C* von Kernighan / Ritchie rein, die diskutieren ausgiebig über die Stringfunktionen.

On 02-Aug-02 Thorsten Haude wrote:

Hi,

* Jan Trippler [02-08-02 21:44]:

...

On Fre, 02 Aug 2002 at 20:46 (+0200), Thorsten Haude wrote:

...

* Bernd Brodesser [02-07-29 11:08]: [str(n)cmp]

...

Bei \0 hört der Vergleich auf.

Das ist die Vermutung. Da sich nichtmal das C:ARM (0-13-326224-3) dazu eindeutig äußert, fände ich einen Beleg hilfreich.

Manno, dann probiers doch aus!

Daß es in der glibc so funktioniert, habe ich schon im Sourcecode nachgesehen.

Also im Zweifelsfall gilt beim Thema C ja wohl der ANSI-Standard oder zur Not noch die "Bibel" (K&R). Alle anderen Aussagen zu dem Thema dürften entweder zu diesen konform sein oder falsch. -- Erhard Schwenk http://www.fto.de - http://www.akkordeonjugend.de No Spam replies please.

On Sam, 03 Aug 2002 at 00:18 (+0200), Thorsten Haude wrote:

* Jan Trippler [02-08-02 21:44]:

...

On Fre, 02 Aug 2002 at 20:46 (+0200), Thorsten Haude wrote:

...

* Bernd Brodesser [02-07-29 11:08]: [str(n)cmp]

...

Bei \0 hört der Vergleich auf.

Das ist die Vermutung. Da sich nichtmal das C:ARM (0-13-326224-3) dazu eindeutig äußert, fände ich einen Beleg hilfreich.

Manno, dann probiers doch aus!

Daß es in der glibc so funktioniert, habe ich schon im Sourcecode nachgesehen.

Ja, und nu?

...

Ein String wird in C _immer_ nullterminiert! Es gibt keine Ausnahmen, ein String ist bei 0 zu Ende. Zeige mir _ein_ Beispiel, in dem das nicht so ist. char versuch[6] = {'k', 'a', 'p', 'u', 't', 't'};

Ein nicht terminierter String, der in jedem Programm Stress machen wird. Das was Du da fabriziert hast, ist einfach nur ein char-Array. Ein String (der als Datentyp in C übrigens nicht existiert) ist ein Null-terminiertes char-Array.

...

Bernds Aussage ist keine Vermutung, sondern Tatsache. Hol Dir die Sourcen, schau nach, baue Testprogramme, ...

Das würde alles nur Aussagen über die glibc erlauben.

Aha, die ist Dir nicht autoritativ genug. Jetzt kenne ich endlich Dein eigentliches Problem: Der Papst muss die 0 am Ende absegnen ;-) [...]

...

P.S.: Du stellst einen Sachverhalt in Frage, der die Grundlage für das gesamte Stringhandling in C bildet.

Bitte? Welcher wäre das wohl?

s. o. Jan

On Sam, 03 Aug 2002 at 20:09 (+0200), Thorsten Haude wrote:

Moin,

* Jan Trippler [02-08-03 16:53]:

...

On Sam, 03 Aug 2002 at 00:18 (+0200), Thorsten Haude wrote:

...

Daß es in der glibc so funktioniert, habe ich schon im Sourcecode nachgesehen.

Ja, und nu?

Nicht alle Systeme laufen mit der glibc.

...

...

...

Ein String wird in C _immer_ nullterminiert! Es gibt keine Ausnahmen, ein String ist bei 0 zu Ende. Zeige mir _ein_ Beispiel, in dem das nicht so ist. char versuch[6] = {'k', 'a', 'p', 'u', 't', 't'};

Ein nicht terminierter String, der in jedem Programm Stress machen wird. Das was Du da fabriziert hast, ist einfach nur ein char-Array. Ein String (der als Datentyp in C übrigens nicht existiert) ist ein Null-terminiertes char-Array.

Ja was denn nun? Ein nicht terinierter String, der nicht existiert?

Siehe unten. Du drehst mir das Wort im Mund rum. versuch[6] ist ein char-Array. Natürlich kannst Du solche char-Arrays - wenn Du es möchtest - ohne 0-Terminierung anlegen (wenn es z. B. für Flags genutzt wird, ist das auch nicht nötig), aber wenn Du _irgendeine_ Stringfunktion drauf loslassen willst, dann _muss_ am Ende eine 0 stehen. Ich habe Dir in meiner anderen Mail ein Code-Beispiel gebracht, das zeigt, wie auch strncmp Unsinn bauen würde, wenn die 0 als String-Ende nicht beachtet wird.

Es geht doch nur darum, daß diese ganze C-Eigenheit mit dem Zeiger-auf-Chararacter offensichtlich und bekannterweise nicht wasserdicht ist. Darum sollte man bei ihrer Benutzung keine Haare spalten, sondern auf Nummer sicher gehen.

Die Haarespalterei machst Du hier. Du behauptest seit Tagen, strcmp liest über die 0 hinweg und das ist Stuss. Du behauptest seit Tagen, dass die Benutzung von strcmp eine Sicherheitslücke ist und das ist Stuss (es sei denn, Du sorgst in Deinen Programmen nicht dafür, dass Strings nullterminiert sind - dann kriegst Du Probleme mit _allen_ Stringfunktionen, selbst die Längenbestimmung mittels strlen raucht dann ab, und strncmp kann in solchen Fällen totalen Schrott liefern - siehe mein Beispiel in der anderen Mail). *Diese ganze unsichere C-Eigenheit* ist dann und nur dann unsicher, wenn sich der Programmierer eben nicht um eine saubere Null-Terminierung (innerhalb der definierten Grenzen des char-Arrays) kümmert.

...

...

...

Bernds Aussage ist keine Vermutung, sondern Tatsache. Hol Dir die Sourcen, schau nach, baue Testprogramme, ...

Das würde alles nur Aussagen über die glibc erlauben.

Aha, die ist Dir nicht autoritativ genug. Jetzt kenne ich endlich Dein eigentliches Problem: Der Papst muss die 0 am Ende absegnen ;-)

Tja, das Programm, an dem ich fast ausschließlich arbeite läuft zum Glück nicht nur auf Linux. (Es existiert sogar ein FAQ-Eintrag wegen einer angeblichen Sicherheitslücke, die von der glibc gemeldet wird, aber nicht existiert.)

Den Satz in Klammern verstehe ich nicht - vor allem nicht, was er hier soll. Nebenbei: Ich entwickele seit einer Reihe von Jahren Programme u. a. in C für diverse Unix-Derivate (Reliant Unix, HP-UX, AIX, Solaris und vereinzelt SCO waren schon dabei), in keinem einzigen Fall hat der strcmp anders als in der glibc funktionert (intern vielleicht, aber er hat _immer_ bei 0 aufgehört).

...

[...]

...

...

P.S.: Du stellst einen Sachverhalt in Frage, der die Grundlage für das gesamte Stringhandling in C bildet.

Bitte? Welcher wäre das wohl?

s. o.

"Strings existierern nicht"? Das würde allerdings das gesamte Stringhandling beeinflussen.

Wieder einmal: Wenn Du zitierst, dann bitte korrekt. So langsam werde ich sauer. O-Ton Jan: ... Ein String (der als Datentyp in C übrigens nicht existiert) ... Ich habe also mitnichten behauptet, dass Strings nicht existieren, sondern dass sie _als Datentyp_ nicht existieren. Das ist ein himmelweiter Unterschied. Wie Strings in C abgebildet werden, hatte ich im gleichen Satz erklärt. Das "s. o." bezog sich auf die Nullterminierung, was jedem halbwegs aufmerksamen Leser wohl auch sofort aufgefallen wäre. Jan

On Sam, 03 Aug 2002 at 21:33 (+0200), Thorsten Haude wrote:

* Jan Trippler [02-08-03 20:37]:

...

Siehe unten. Du drehst mir das Wort im Mund rum.

Die Gelegenheit war günstig.

aber nicht glücklich gewählt - manche Leute (u. a. ich) reagieren sauer, wenn aus fachlicher Diskussion Polemik wird.

...

versuch[6] ist ein char-Array. Natürlich kannst Du solche char-Arrays - wenn Du es möchtest - ohne 0-Terminierung anlegen (wenn es z. B. für Flags genutzt wird, ist das auch nicht nötig), aber wenn Du _irgendeine_ Stringfunktion drauf loslassen willst, dann _muss_ am Ende eine 0 stehen.

Die ist aber schon bewußt, daß diese Dinge auch durch Fehler anderswo bzw. durch Angriffe passieren können, oder? Darum sollte C-Code idR. so robust wie möglich sein, nicht so schnell wie möglich.

Aber auch nur so komplex wie nötig. Auch das ist eine Frage der Robustheit. Man kann auch die Prüfungen im Programm übertreiben. Der Grundsatz sollte lauten: Jedes Datum aus einer unsicheren Quelle wird sofort bei seinem Eingang im Programm geprüft. Dann muss man das nicht bei jeder Operation noch mal machen (vor allem dann nicht, wenn das Datum - in diesem Fall der String - gar nicht verändert wird). Dein Aussage robust vs. schnell ist so absolut nicht richtig. Wie überall gilt auch hier: Aufwand und Nutzen müssen sich entsprechen.

...

...

Es geht doch nur darum, daß diese ganze C-Eigenheit mit dem Zeiger-auf-Chararacter offensichtlich und bekannterweise nicht wasserdicht ist. Darum sollte man bei ihrer Benutzung keine Haare spalten, sondern auf Nummer sicher gehen.

Die Haarespalterei machst Du hier. Du behauptest seit Tagen, strcmp liest über die 0 hinweg und das ist Stuss.

Ich behaupte nur, daß ich nicht sicher wissen kann, daß es anders ist.

Auch das ist Stuss.

...

Du behauptest seit Tagen, dass die Benutzung von strcmp eine Sicherheitslücke ist und das ist Stuss

Ich behaupte, daß das Leben zu kurz und strncmp() zu billig ist, um darüber nachdenken zu müssen.

Das habe ich gerade in meiner Mail an Andre Heine geschrieben: Genau das *nicht darüber nachdenken* ist gefährlich. Und strncmp() ist allein vielleicht billig, wenn aber mehrere zigtausend Durchläufe diesen zusätzlichen Aufwand treiben, sicher nicht mehr. Das Aasen mit den zur Verfügung stehenden Ressourcen ist auch nicht gerade das Nonplusultra guter Programmierung.

...

Ich entwickele seit einer Reihe von Jahren Programme u. a. in C für diverse Unix-Derivate (Reliant Unix, HP-UX, AIX, Solaris und vereinzelt SCO waren schon dabei), in keinem einzigen Fall hat der strcmp anders als in der glibc funktionert (intern vielleicht, aber er hat _immer_ bei 0 aufgehört).

Das ist gut, dann kennst Du vielleicht auch einen Beweis, der nicht nur anekdotisch ist. Daß es strcmp()s gibt, die sich so vernünftig verhalten, wie erwartet, haben wir ja schon geklärt.

*anekdotisch* - Du verstehst es, Dinge in das rechte Licht zu rücken :-( - Du stehst nicht zufällig bei der nächsten Wahl als Kandidat auf einer Liste? Um eine weitere Anekdote hinzuzufügen: auch im Borland Turbo C++, Borlands C++-Builder und in M$ Visual C++ hören die strcmp bei der ersten Null auf. Kehren wir die Frage mal um: Kennst du einen strcmp(), der sich _nicht_ so vernünftig verhält? Oder wie wärs mal mit ein wenig Logik? strcmp ist (neben strncmp) eine _String_-Funktion. Strings sind nullterminierte char-Arrays. Welchen Sinn sollte es für eine String-Funktion machen, einen String über seinen Terminator hinaus zu bearbeiten? [...]

Tut mir leid, ich hätte es nicht als wörtliches Zitat markieren sollen, aber wenn es keinen Typ String gibt, gibt es auch keine Strings: Gerade darum muß man ja durch so viele Reifen springen, wenn man in C Strings verarbeitet.

Auch dies ist wieder mal eine typisch Haude'sche Schlussfolgerung. Natürlich gibt es in C Strings: Das sind nullterminierte char-Arrays. Durch wie viele Reifen muss ich denn springen, um in C Strings zu verarbeiten? _Du_ baust doch immer wieder neue Reifen auf, offenbar willst Du ja springen? Ich versuche Dir die ganze Zeit zu erklären, dass Du die Hälfte Deiner Reifen einpacken kannst. /* Int deklarieren: */ int i; /* char-Array deklarieren */ char s[16]; /* int zuweisen */ i = 0; /* String zuweisen */ strcpy (s, "String"); /* int vergleichen */ if (i == 0) ... /* String vergleichen */ if (! strcmp (s, "String")) ... Wenn Du _gesicherte_ Zuweisungen haben willst, musst Du sowohl bei numerischen als auch bei allen char-basierten Werten zusätzlichen Aufwand treiben. Jan

Moin, * Bernd Brodesser [02-08-03 22:56]:

* Jan Trippler schrieb am 03.Aug.2002:

...

Die Haarespalterei machst Du hier. Du behauptest seit Tagen, strcmp liest über die 0 hinweg und das ist Stuss. Du behauptest seit Tagen,

Natürlich ist es Stuss. Es muß Stuss sein, wenn es nicht Stuss wäre, wie könnte dann ein strcmp jemals ein gleich, sprich eine 0 als Rückgabewert habe?

Man sollte nie davon ausgehen, daß das Gegenüber das Offensichtliche erkennt. Tut mir leid, Eure Zeit verplempert zu haben. Thorsten -- You're not supposed to be so blind with patriotism that you can't face reality. Wrong is wrong, no matter who does it or who says it. - Malcolm X

Hallo Ralf, * Ralf Corsepius schrieb am 04.Aug.2002:

Am Sam, 2002-08-03 um 22.56 schrieb Bernd Brodesser:

...

Ein String ist immer ein Zeiger auf ein Byte, bei jeder Programmierpsrache.

Kommt darauf an, wie Du das meinst. Man kann String auch als abstraktes Konzept oder als Datentyp zur Verarbeitung von textuellen Zeichenketten auffassen.

...

Es ist nur manchmal gut vor dem Anwender versteckt, aber wie soll man sonst ein String definieren, wenn nicht als Zeiger? S.o.

Viele Programmiersprachen kennen derartige Datentypen, deren Details ein Programmierer nicht kennen soll/darf/muss.

Ja. Aber intern wird immer ein Zeiger auf eine Speicherstelle abgespeichert. Vielleicht zusätzlich noch die Länge. Auch C kennt Datentypen, deren Details ein Programmierer nicht kennen muss. float bzw. double wird in Mantisse und Exponent aufgeteilt. Wie genau das vonstatten geht, interessiert den Anwender nicht.

Pascal/Modula Strings z.B. führen Längenfelder mit sich und entsprechen inetwa folgendem C-Struct

struct String { size_t len ; char *char_array; }

Auch das C++ string<T>-Template arbeitet nach ähnlichen Muster.

Vorteil: Anders als in C braucht man sich nicht um terminierende \0-en zu kümmern: Nachteil: In der Regel deutlich höherer Verwaltungsoverhead, spürbare Geschwindigkeitseinbussen und Probleme bei Low-Level IO (Fehlt in der Pascal-Sprachdefinition völlig).

Eben. Bernd -- ROTFL = Rolling On The Floor, Laughing = Auf dem Boden wälzen, lachend. SCNR = Sorry, Could Not Resist = Sorry, Ich konte nicht wiederstehen. AFAIK = As Far As I Know = So weit ich weis|BTW = By The Way = Nebenbei bemerkt IMHO = In My Humble Opinion = meiner bescheidenen Meinung nach |Zufallssig. 9

Moin, * Jan Trippler [02-07-30 00:53]:

On Son, 28 Jul 2002 at 23:47 (+0200), Thorsten Haude wrote:

...

* Jan Trippler [02-07-28 21:26]:

...

On Sam, 27 Jul 2002 at 07:16 (+0200), David Haller wrote:

...

+ if( hrv == 0 && ! ( (use_fqdn = getenv("EVOLUTION_MSGID_FQDN")) != NULL + && strncmp(use_fqdn, "no\0", 3) == 0) ) {

Nur mal so am Rande: Welchen Sinn hat es hier, strncmp() statt schlicht strcmp(use_fqdn, "no") zu nutzen? strncmp() vergleicht auch nur _höchstens_ 3 Byte, maximal aber bis zum ersten Null-Byte. In welchem Fall also sollte sich hier strncmp anders verhalten als strcmp?

Laut dem C:ARM vergleicht strcmp() bis zum ersten Unterschied. Es wird erwähnt, daß die Strings Null-terminiert sein sollen, aber nicht explizit, daß er bei der \0 aufhört, zu vergleichen.

Selbst wenn es so wäre: "no" hat an 3. Position einen 0-Wert. Hat ihn der erste auch - gut, wenn nicht - auch gut, dann sind die beiden Strings also ungleich. qed! Wo also liegt in diesem Fall der Vorteil von strncmp()? Da steckt eine Konstante im Vergleich!

Es kann sein, daß er nach der dritten Position weiter vergleicht.

...

Außerdem spart das strncmp() jeden weiteren Gedanken über das Thema und ist darum per se besser.

*Umpf* Das ist wohl etwas unüberlegt (vorsichtig formuliert). Beispiel:

Gleichheit von zwei _variablen_ Strings unbekannter Länge prüfen. Bis zu welchem Byte prüfst Du? Machst Du erstmal eine strlen() Berechnung, um einen Anhaltspunkt zu haben? Findest du das effizient, wenn das z. B. innerhalb einer Schleife mit mehreren 10^x Iterationen laufen muss? Welche Länge nimmst du als Parameter? String1 oder String2? Sicher alles lösbar, aber nochmal: Was bringt es Dir?

Was bringt mir was? Strings unbekannter Länge in C sind bei mir tatsächlich beliebig unbeliebt, also würde ich sie entweder zählen oder besser noch nicht zulassen.

Du hast bei einem strncmp() _immer_ den zusätzlichen Aufwand, die String-Länge prüfen, bestimmen, übergeben zu müssen.

Nein, gewöhnlich haben Strings eine #definierte maximale Länge, die man dann auch nett in strncmp() benutzen kann.

Du musst in einem C-Programm doch sowieso dafür sorgen, dass alle Deine Strings sauber mit 0 terminiert sind - der strcmp() wird immer ein sauberes Ergebnis bringen. Selbst wenn nicht explizit bei 0 aufgehört wird, ist der Umstand, dass ein String zu Ende ist(0) und der andere nicht (!=0) ein Unterschied, der zu einem Returncode != 0 führt.

Was aber, wenn beide auf \0 enden?

BTW: Der Code wird für einen Außenstehenden in der Regel leichter lesbar sein, wenn er sich nicht pausenlos fragen muss, aus welchem Grund denn ein Stringvergleich auf x Bytes begrenzt wird, nur um dann festzustellen, dass ja doch implizit der ganze String geprüft wird.

Der Code wird im Gegenteil dann leichter lesbar sein, wenn sich der Leser nicht auch noch darüber Gedanken machen muß, ob mal wieder eine Funktion aus string.h aus dem Ruder läuft. Thorsten -- Verbing weirds language. - Calvin.

Moin, * Jan Trippler [02-08-02 22:04]:

On Fre, 02 Aug 2002 at 20:52 (+0200), Thorsten Haude wrote:

...

Was bringt mir was? Strings unbekannter Länge in C sind bei mir tatsächlich beliebig unbeliebt, also würde ich sie entweder zählen oder besser noch nicht zulassen.

Die Länge eines Strings in C ist _nie_ unbekannt. Nutze strlen(), dann erfährst auch Du sie!

Ähh... *Du* hattest angedeutet, daß ein strlen zu teuer ist.

...

...

Du hast bei einem strncmp() _immer_ den zusätzlichen Aufwand, die String-Länge prüfen, bestimmen, übergeben zu müssen.

Nein, gewöhnlich haben Strings eine #definierte maximale Länge, die man dann auch nett in strncmp() benutzen kann.

Gewöhnlich haben _statisch_ deklarierte Strings eine definierte maximale Länge - was ist mit dynamisch erzeugten (Stichwort malloc)?

An welchen Programmen hast Du bisher gearbeitet? Kann man die #definierte Länge wohl auch dazu benutzen, einen String zu allozieren? Wenn nein, warum nicht?

Und auch bei statischen Strings musst Du rechnen, nämlich dann, wenn die Definitionen zweier Strings sich unterscheiden. Dann musst Du nämlich feststellen, welche der beiden Längen Du nimmst.

min(len1, len2)

Das willst du alles hart kodiert in das Programm schreiben? Wie flexibel und gut wartbar ;-)

Dafür gibt's #defines.

...

...

Du musst in einem C-Programm doch sowieso dafür sorgen, dass alle Deine Strings sauber mit 0 terminiert sind - der strcmp() wird immer ein sauberes Ergebnis bringen. Selbst wenn nicht explizit bei 0 aufgehört wird, ist der Umstand, dass ein String zu Ende ist(0) und der andere nicht (!=0) ein Unterschied, der zu einem Returncode != 0 führt.

Was aber, wenn beide auf \0 enden?

Das tun sie sowieso. Und wenn sie an der gleichen Stelle mit 0 enden, dann sind sie gleich lang ;-) Wenn strcmp() bis hierher gekommen ist, dann sind sie sogar gleich! Und dann hört er auf - unabhängig davon, was danach kommt (noch ein kleines Beispiel):

Das ist nochmal eine schöne Zusammenfassung von dem, worum es hier geht. Allerdings ist immer noch unklar, ob über die \0 hinaus verglichen wird.

...

Der Code wird im Gegenteil dann leichter lesbar sein, wenn sich der Leser nicht auch noch darüber Gedanken machen muß, ob mal wieder eine Funktion aus string.h aus dem Ruder läuft.

Diese Begründung ist ja nun absoluter Quatsch, sorry! Woher soll denn Dein Leser wissen, dass nicht strncmp() aus dem Ruder läuft?

Sinnvollerweise benutzt man für das n den gleichen Wert, der für die Allozierung des Strings benutzt worden ist. Dieser Wert hat dann noch einen brauchbaren Namen wie MAX_PATH_LEN, dann kann man das schon erkennen. Thorsten -- Quidquid latine dictum sit, altum viditur.

Moin, * Bernd Brodesser [02-08-03 10:08]:

* Thorsten Haude schrieb am 03.Aug.2002:

...

* Jan Trippler [02-08-02 22:04]: Was ist, wenn man z.B eine Zeile einer Datei oder der Standardeingabe einliest? So eine Zeile ist normalerweise max. 80 Zeichen lang, kann aber sehr, sehr viel länger sein. Wenn es eine Datei von 2GB ist und sie kein \n enthält, dann ist diese eine Zeile verdammt lang. Wo willst Du da die Grenze legen?

Sowas habe ich noch nicht gemacht. An der Stelle muß man natürlich besondere Vorsichtsmaßnahmen treffen, wie immer bei fremden Strings.

...

Kann man die #definierte Länge wohl auch dazu benutzen, einen String zu allozieren? Wenn nein, warum nicht?

Wenn ich eine feste Länge habe, warum sollte ich dann noch dynamisch allozieren?

Um den Speicherplatz wieder freigeben zu können.

...

...

Und auch bei statischen Strings musst Du rechnen, nämlich dann, wenn die Definitionen zweier Strings sich unterscheiden. Dann musst Du nämlich feststellen, welche der beiden Längen Du nimmst.

min(len1, len2)

Schon flahsc. Dann wäre foo und foobar gleich, da nur die ersten drei Zeichen, die Länge von foo, verglichen wird. Ok, wenn Du noch eins hinzuaddierst, dann funktioniert es.

Ja, natürlich. Ich hatte nicht angenommen, daß ich das so haarklein beschreiben muß.

Aber was ist das für einen Aufwand?

Kein besonders großer; wenn alle String konstante Längen haben kann das der Compiler erledigen. Im Übrigen ist das Tempo in 99% der Fälle nicht so wichtig (weil eh schnell genug) wie die Sicherheit vor Bufferproblemen.

Wenn es nur ein einziger, oder wenige Vergleiche sind, so ist das sicherlich egal. Aber gerade Vergleiche können sehr, sehr häufig vorkommen. Denk mal an Sortierprogramme.

Mache ich nicht, weil man in dem Fall die Strings von Anfang an anders verwalten kann.

...

...

Das willst du alles hart kodiert in das Programm schreiben? Wie flexibel und gut wartbar ;-)

Dafür gibt's #defines.

Der Wert wird beim Compelieren festgelegt. Was ist, wenn ein und die Gleiche Funktion von verschiedene Programmteile benutzt wird, die ganz unterschiedliche Längen haben?

Dann wird die Länge mit übergeben.

...

...

...

Der Code wird im Gegenteil dann leichter lesbar sein, wenn sich der Leser nicht auch noch darüber Gedanken machen muß, ob mal wieder eine Funktion aus string.h aus dem Ruder läuft.

Diese Begründung ist ja nun absoluter Quatsch, sorry! Woher soll denn Dein Leser wissen, dass nicht strncmp() aus dem Ruder läuft?

Sinnvollerweise benutzt man für das n den gleichen Wert, der für die Allozierung des Strings benutzt worden ist. Dieser Wert hat dann noch einen brauchbaren Namen wie MAX_PATH_LEN, dann kann man das schon erkennen.

Was aber, wenn er ständig anders ist, und man ihm kompliziert ermitteln müßte? Etwas die Zeilenlänge innerhalb einer Datei?

Kompliziert? Thorsten -- Die Zensur ist das lebendige Geständnis der Großen, daß sie nur verdummte Sklaven aber keine freien Völker regieren können. - Johann Nepomuk Nestroy

Moin, * Jan Trippler [02-08-03 17:06]:

On Sam, 03 Aug 2002 at 10:45 (+0200), Thorsten Haude wrote:

...

* Bernd Brodesser [02-08-03 10:08]:

...

Wenn ich eine feste Länge habe, warum sollte ich dann noch dynamisch allozieren?

Um den Speicherplatz wieder freigeben zu können.

Trotzdem bleibt die Verschwendung von Speicher, weil ein #define ja den größtmöglichen Wert abbilden muss.

Ja. Ich habe nie behauptet, daß C perfekt ist.

wenn es z. B. um große Listen geht, kommt da eine Menge Holz zusammen, die auch im Zeitalter der GB-Speicher nicht zu vernachlässigen ist.

*Mir* ist klar das nicht jede Regel überall gilt.

...

Im Übrigen ist das Tempo in 99% der Fälle nicht so wichtig (weil eh schnell genug) wie die Sicherheit vor Bufferproblemen.

Wo hast Du _das_ denn her?

Aus der Praxis. Ist interessant da, ich kann Dir ja mal eine Karte schicken.

Nebenbei: Du betreibst Demagogie, Du behauptest nämlich implizit, dass die Verwendung von strcmp() Bufferprobleme verursacht - womit Du immer noch allein bist.

Ich behaupte nur, daß ich darüber nicht nachdenken will, und darum strncmp verwende, wenn es sich irgendwie einrichten läßt.

...

...

Wenn es nur ein einziger, oder wenige Vergleiche sind, so ist das sicherlich egal. Aber gerade Vergleiche können sehr, sehr häufig vorkommen. Denk mal an Sortierprogramme.

Mache ich nicht, weil man in dem Fall die Strings von Anfang an anders verwalten kann.

Wie?

Ich habe mich schlecht ausgedrückt: Man kann in diesem Fall mit anderen Methoden sicherstellen, das es keine Probleme mit überschrittenen Buffergrenzen gibt.

...

...

...

...

Das willst du alles hart kodiert in das Programm schreiben? Wie flexibel und gut wartbar ;-)

Dafür gibt's #defines.

Der Wert wird beim Compelieren festgelegt. Was ist, wenn ein und die Gleiche Funktion von verschiedene Programmteile benutzt wird, die ganz unterschiedliche Längen haben?

Dann wird die Länge mit übergeben.

Und wieder ein Parameter mehr, der den Stack belastet und zur potenziellen Fehlerquelle wird (short - int - long - unsigned - 32 Bit - 64 Bit, ...) - und der natürlich in den Funktionen ebenfalls zu größerer Komplexität führt.

Du liebe Güte, Du hörst sich an, also würdest Du C und Ruby ein wenig durcheinanderbringen. Ja, in C muß man gelegentlich Dinge tun, die etwas unhandlich sind. Das liegt daran, daß die Sprache auf einer niedrigen Ebene funktioniert und (aufgepaßt:) keinen Stringtyp kennt. Ich habe wie gesagt die meiste Erfahrung mit einem einzigen Programm (NEdit) gemacht, und darum auch nur mit einer relativ kleinen Gruppe von Lehrern/Mitentwicklern. Vielleicht hast Du ja Beispiele aus einem anderen Programm, wie man mit Strings umgeht? Ich lerne immer gerne dazu, besonders in diesem Zusammenhang. Thorsten -- The privacy of correspondence, posts and telecommunications shall be inviolable. - German Grundgesetz, Article 10, Sec. 1

On Sam, 03 Aug 2002 at 20:49 (+0200), Andre Heine wrote:

Am Samstag, 3. August 2002 20:24 schrieb Thorsten Haude:

...

* Jan Trippler [02-08-03 17:06]:

...

On Sam, 03 Aug 2002 at 10:45 (+0200), Thorsten Haude wrote:

[...] Ich linke mich jetzt mal dazu :))

...

...

Nebenbei: Du betreibst Demagogie, Du behauptest nämlich implizit, dass die Verwendung von strcmp() Bufferprobleme verursacht - womit Du immer noch allein bist.

IMHO sollte man bei C99 lieber strncmp, strncat, strncpy, usw. verwenden.

Sorry, ich kenne leider den ganzen Thread nicht. Durch strcmp() können IMHO Puffer Überläufe passieren, man sollte gerade bei der string Verarbeitung aufpassen.

Sorry, das sind Gemeinplätze. Schau Dir den Anfang des Threads an, damit Du verstehst, wie diese Diskussion zustande kam. BTW: man sollte bei der Programmierung immer aufpassen - nicht nur bei Strings (um auch mal einen Gemeinplatz beizusteuern).

Jedenfalls wenn man mit Sockets arbeitet, ein Server kann einem soetwas sehr übel nehmen.

JEDES Programm nimmt Buffer Overflows übel. Es führt in den meisten Fällen zu einer ungewollten Programmfortführung (oder -beendigung).

ZITAT: "Es ist bemerkenswert, wie viele Einbrüche durch einen Hacker zustande kamen, der so viele Daten sendete, daß der Server-Aufruf von sprintf Puffer zum Überlaufen brachte. Weitere Funktionen, mit denen wir vorsichtig sein sollten, sind gets, strcat,strcpy. Statt dessen sollten wir üblicherweise fgets, strncat und strncpy verwenden. Zusätzliche Hinweise zum Aufbau von sicheren Netzwerkenprogrammen finden Sie im Kapitel 23 von[Garfinkel und Spafford 1996]"

Aus dem Buch "Programmieren von UNIX-Netzwerken", Hanser Verlag.

Was meinst Du, warum strcmp in diesem Zitat nicht auftaucht ... Zu dem Zitat: Es geht hier IMHO um eine bestimmte Art von Stringhandling: Die Zuweisung von Werten unbekannter Herkunft an einen String. Alle diese Funktionen haben gemeinsam, dass sie die Quell-Strings ungeprüft (bis zum ersten auftretenden 0 - sic!) an das Ziel übergeben. Es wird keine Prüfung durchgeführt, ob die Deklaration des Zielpuffers ausreichend ist - das geht aus 2 Gründen nicht: - die aufgerufene Funktion kennt die Deklaration nicht (sie kriegt einen Pointer als Parameter) - die Größe kann zur Compile-Zeit unbekannt sein (dynamische Puffer). Der Buffer Overflow tritt aus genau einem Grund auf: Der Programmierer hat einen String aus unsicherer Quelle nicht ausreichend geprüft. Wenn das geschieht, kann man diese Funktionen auch einsetzen. Ein Schutz kann u. a. mit Hilfe von strncat, strncpy, fgets passieren, die eine Maximallänge zu kopierender Zeichen erwarten; denkbar sind aber auch Konstrukte wie: while (i < sizeof buf) *(buf + i++) = fgetc(file); oder: sprintf (format, "%%-.%ds", sizoef (buf) - 1); sprintf (buf, format, eingabe); oder: ...

IMHO ist das genauso mit strcmp(), mag mich aber täuschen...

Was bringt Dich auf diesen Gedanken? Alle im Zitat genannten Funktionen weisen Strings Werte zu, str(n)cmp vergleicht Strings. strcmp ist nur dann ein Risiko, wenn einer der beiden Parameter nicht sauber nullterminiert ist. Und dann kann strcmp eben einfach durch den Speicher sausen und bei der ersten Unstimmigkeit (oder 0!) anhalten. Wenn ich ein Programm baue, dem erst an dieser Stelle auffällt, das da was nicht stimmen könnte - ... Zum x-ten Mal: Die Diskussion begann, als Thorsten Haude behauptete, man könne sich nicht sicher sein, ob strcmp() am Stringende (Wert des Bytes = 0) aufhört zu vergleichen - und das ist nun mal Quatsch!

...

Ich behaupte nur, daß ich darüber nicht nachdenken will, und darum strncmp verwende, wenn es sich irgendwie einrichten läßt.

ACK.

NACK! Wenn ich anfange, in Programmen nicht mehr über die Zweckmäßigkeit dieser (strcmp) oder jener (strncmp) Funktion nachzudenken, dann sollte ich mir einen anderen Job suchen. Wie im Thread bereits mehrmals erwähnt bedeutet der Einsatz von strncmp immer, dass ich mir Gedanken darüber machen muss, wie weit ich den Vergleich laufen lasse. Das kann einfach sein (statische Strings, wohldefinierte Größen), kann aber im Falle von dynamisch erzeugten Strings auch ziemlich aufwändig werden - vor allem dann, wenn ich diese Berechnung sehr oft machen muss.

...

...

...

...

Wenn es nur ein einziger, oder wenige Vergleiche sind, so ist das sicherlich egal. Aber gerade Vergleiche können sehr, sehr häufig vorkommen. Denk mal an Sortierprogramme.

Server z.B., DOS Attacken, etc...

Was sollen uns diese Begriffe jetzt sagen? Jan

On Sam, 03 Aug 2002 at 23:27 (+0200), Bernhard Walle wrote:

On Sat, 03 Aug 2002 at 22:43 (+0200), Jan Trippler wrote:

...

On Sam, 03 Aug 2002 at 20:49 (+0200), Andre Heine wrote:

...

Am Samstag, 3. August 2002 20:24 schrieb Thorsten Haude:

...

* Jan Trippler [02-08-03 17:06]:

...

On Sam, 03 Aug 2002 at 10:45 (+0200), Thorsten Haude wrote:

[...] Ich linke mich jetzt mal dazu :)) [...]

Könntet ihr vielleicht aufhören, eine Diskussion parallel über zwei Listen zu führen (suse-programming, suse-linux)?

Sorry, ich habe die doppelten Einträge im To nicht gesehen, sonst hätte ich suse-programming gelöscht - für mich ist der Thread aber eh beendet. Deshalb nochmal an beide Listen. Jan

On Sam, 03 Aug 2002 at 00:34 (+0200), Thorsten Haude wrote:

* Jan Trippler [02-08-02 22:04]:

...

On Fre, 02 Aug 2002 at 20:52 (+0200), Thorsten Haude wrote:

...

Was bringt mir was? Strings unbekannter Länge in C sind bei mir tatsächlich beliebig unbeliebt, also würde ich sie entweder zählen oder besser noch nicht zulassen.

Die Länge eines Strings in C ist _nie_ unbekannt. Nutze strlen(), dann erfährst auch Du sie!

Ähh... *Du* hattest angedeutet, daß ein strlen zu teuer ist.

Ja, das meine ich auch nach wie vor. Mir ging es um Deinen Satz mit den unbekannten String-Längen. Was machst du hier für eine Argumentation? Du hast was gegen Strings unbekannter Länge, ich nenne strlen. Du willst strncmp nutzen, weil Du (was ich immer noch nicht kapiere) behauptest, dass strcmp über die 0 hinwegliest (oder lesen könnte). Ich behaupte, dass dann immer zusätzlicher Aufwand durch die Ermittlung der Länge auftaucht. Was widerspricht sich da in meiner Argumentation?

...

...

...

Du hast bei einem strncmp() _immer_ den zusätzlichen Aufwand, die String-Länge prüfen, bestimmen, übergeben zu müssen.

Nein, gewöhnlich haben Strings eine #definierte maximale Länge, die man dann auch nett in strncmp() benutzen kann.

Gewöhnlich haben _statisch_ deklarierte Strings eine definierte maximale Länge - was ist mit dynamisch erzeugten (Stichwort malloc)?

An welchen Programmen hast Du bisher gearbeitet? Kann man die #definierte Länge wohl auch dazu benutzen, einen String zu allozieren? Wenn nein, warum nicht?

Weil man sie nicht vorher kennt! Was für Programme hast _Du_ denn bisher geschrieben? Wenn ich von vornherein weiss, wie lang ein String werden kann, dann mache ich mir i.d.R. nicht den Aufwand, ihn zur Laufzeit dynamisch zu erzeugen. Aber wenn ich z. B. eine verkettete Liste aufbaue, in der Strings unbekannter Länge landen können (z. B. fremdsprachige Texte in einem Programm, Pfadnamen, ...), dann werde ich den Teufel tun und sie mit einer Maximallänge generieren - das ist unnötige Platzverschwendung (was auch bei heutigen Speichergrößen nicht unwesentlich ist, wenn so eine Liste mehrere Tausend Einträge hat).

...

Und auch bei statischen Strings musst Du rechnen, nämlich dann, wenn die Definitionen zweier Strings sich unterscheiden. Dann musst Du nämlich feststellen, welche der beiden Längen Du nimmst.

min(len1, len2)

Ja, z. B. - also zusätzlicher (unnötiger) Aufwand.

...

Das willst du alles hart kodiert in das Programm schreiben? Wie flexibel und gut wartbar ;-)

Dafür gibt's #defines.

Und jedesmal ein neuer Build, wenn sich irgendwo eine Länge ändert. Cool! Den Versionszähler kann man sich dann als Ventilator in die Küche hängen ;-) [...]

Das ist nochmal eine schöne Zusammenfassung von dem, worum es hier geht. Allerdings ist immer noch unklar, ob über die \0 hinaus verglichen wird.

Da Du den Code-Schnipsel offensichtlich nicht gelesen / verstanden hast, hier noch mal eine kommentierte Version: <schnipp> #include int main (int argc, char *argv[]) { char s1[512], s2[256]; /* beide String ueber die gesamte Länge mit 0 initialisieren */ memset (s1, 0, sizeof s1); memset (s2, 0, sizeof s2); /* in beide Strings die Zeichenfolge "ein string" kopieren ab Stelle 0, also von Stelle 0 - 9 mit dem Text belegen */ strcpy (s1, "ein string"); strcpy (s2, "ein string"); /* in String 1 an Stelle 10 + 2 = 12 das Zeichen mit dem ASCII-Wert 1 kopieren */ *(s1 + strlen (s1) + 2) = 1; /* in String 2 an Stelle 10 + 2 = 12 das Zeichen mit dem ASCII-Wert 2 kopieren */ *(s2 + strlen (s2) + 2) = 2; /* Beide Strings haben jetzt von Stelle 0 - 9 den Text "ein string" stehen, an den Stellen 10 und 11 stehen 0-Werte und an Stelle 12 unterscheiden sich die beiden Strings: in s1 steht 1, in s2 steht 2. _Wenn_ strcmp also nicht aufhören würde, wenn eine 0 in einem der beiden Strings auftaucht, müsste der nachfolgende strcmp einen Wert <> 0 liefern (es sollte dann 1 sein, weil s2 > s1 wäre - wenn nicht bei Stelle 10 Schluss wäre) */ return (strcmp (s1, s2)); } <schnapp>

...

...

Der Code wird im Gegenteil dann leichter lesbar sein, wenn sich der Leser nicht auch noch darüber Gedanken machen muß, ob mal wieder eine Funktion aus string.h aus dem Ruder läuft.

Diese Begründung ist ja nun absoluter Quatsch, sorry! Woher soll denn Dein Leser wissen, dass nicht strncmp() aus dem Ruder läuft?

Sinnvollerweise benutzt man für das n den gleichen Wert, der für die Allozierung des Strings benutzt worden ist. Dieser Wert hat dann noch einen brauchbaren Namen wie MAX_PATH_LEN, dann kann man das schon erkennen.

Nochmal: Geh doch mal auf Deine eigenen Argumente ein: *...Funktion aus string.h aus dem Ruder läuft...*; Ich: *..wissen, dass nicht strncmp() aus dem Ruder läuft...* - was hat diese Deine Antwort mit dem Text darüber zu tun? BTW: Gehen wir mal davon aus, dass strcmp() nicht bei 0 aufhört. Dann sollte man doch davon ausgehen, dass auch strncmp() nicht bei 0 aufhört, oder? Dann müsste aber der folgende Code-Schnipsel ein ziemlich merkwürdiges Resultat ergeben: <schnipp> #include #include #define C_TXTLEN 16 int main (int argc, char *argv[]) { char s1[C_TXTLEN], s2[C_TXTLEN]; /* beide String ueber die gesamte Länge mit 0 initialisieren */ memset (s1, 0, C_TXTLEN); memset (s2, 0, C_TXTLEN); /* in beide Strings die Zeichenfolge "ein string" kopieren ab Stelle 0, also von Stelle 0 - 9 mit dem Text belegen */ strcpy (s1, "ein string"); strcpy (s2, "ein string"); /* erster Vergleich */ printf ("(s1 = <%s>) == (s2 = <%s>)? %s\n", s1, s2, strncmp (s1, s2, C_TXTLEN) ? "Nein" : "Ja"); /* in String 2 an Stelle 7 eine 0 kopieren */ *(s2 + 7) = 0; /* zweiter Vergleich */ printf ("(s1 = <%s>) == (s2 = <%s>)? %s\n", s1, s2, strncmp (s1, s2, C_TXTLEN) ? "Nein" : "Ja"); return (0); } <schnapp> Jan

On Sam, 03 Aug 2002 at 20:52 (+0200), Thorsten Haude wrote: [...]

Ok, das führt mir alles zu weit weg. Es gibt bestimmt eine Menge Fälle, in denen man strcmp() benutzen soll, aber eben auch Fälle, in denen es nicht nötig ist.

Es gibt Fälle, in denen man strncmp() benutzen soll (wenn einen z. B. nur die ersten n Zeichen eines Strings interessieren), ansonsten ist es nicht nötig. Es bedeutet zusätzlichen Aufwand, der meist unnötig ist. [Ermittlung der String-Länge]

Ich sehe nicht, daß es garantiert in allen Fällen unnötig ist.

Nein, in allen nicht. Aber in dem, an dem sich diese Diskussion hier entzündete schon.

...

...

...

Das willst du alles hart kodiert in das Programm schreiben? Wie flexibel und gut wartbar ;-)

Dafür gibt's #defines.

Und jedesmal ein neuer Build, wenn sich irgendwo eine Länge ändert. Cool! Den Versionszähler kann man sich dann als Ventilator in die Küche hängen ;-)

Huh? Warum sollte sich die Länge so häufig ändern.

Das war ein Witz - deshalb auch der Smiley. Solche Längen werden sich nicht oft ändern, aber ab und zu schon. Wenn ich nur wegen der Verwendung solcher #defines in strncmp und Konsorten ständig neue Versionen bauen muss, ist das unnötig - das meinte ich damit. [...]

Man benutzt halt einen festgelegten Wert für die Allozierung und den gleichen Wert für die Begrenzung der strn*-Funktionen. Das ist auch kein geheimer Trick, sondern relativ naheliegend, darum kann das auch der Leser wissen.

Mir fehlte der Zusammenhang. Du hast sinngemäß geschrieben, dass dem Leser den Code dann übersichtlicher wird, wenn er sich nicht noch Gedanken darüber machen muss, ob wieder eine Funktion aus string.h *aus dem Ruder gelaufen ist*. Ich habe daraufhin erwidert, dass er sich da bei strncmp genausowenig wie strcmp sicher sein kann, es also keinen Unterschied macht. Wie man defines verwendet, ist mir schon klar ;-)

...

BTW: Gehen wir mal davon aus, dass strcmp() nicht bei 0 aufhört. Dann sollte man doch davon ausgehen, dass auch strncmp() nicht bei 0 aufhört, oder?

Man sollte nicht davon ausgehen, daß es nicht passiert. Wahrscheinlich ist es nicht.

Ja, hmm - äh wie nochmal? Stimmst Du mir zu oder behauptest Du, dass strncmp eine gänzlich andere Implementierung vorlegt als strcmp?

...

Dann müsste aber der folgende Code-Schnipsel ein ziemlich merkwürdiges Resultat ergeben:

Ich hab's nicht verstanden, was meinst Du?

Sorry, ich sah gerade, dass da noch eine Kleinigkeit fehlt, um meine Argumentation verständlich zu machen, das ergänze ich hier mal. Ich habe auch zum Vergleich noch die strcmp-Werte angehängt, um zu zeigen, dass es keinen Unterschied macht (wäre ja auch schlimm in diesem Fall). <schnipp> #include #include #define C_TXTLEN 16 int main (int argc, char *argv[]) { char s1[C_TXTLEN], s2[C_TXTLEN]; /* beide String ueber die gesamte Länge mit 0 initialisieren */ memset (s1, 0, C_TXTLEN); memset (s2, 0, C_TXTLEN); /* in beide Strings die Zeichenfolge "ein string" kopieren ab Stelle 0, also von Stelle 0 - 9 mit dem Text belegen */ strcpy (s1, "ein string"); strcpy (s2, "ein string"); /* erster Vergleich: Die Strings sind gleich, also lautet die Ausgabe: (s1 = <ein string>) == (s2 = <ein string>)? strncmp: Ja; strcmp: Ja */ printf ("(s1 = <%s>) == (s2 = <%s>)? strncmp: %s; strcmp: %s\n", s1, s2, strncmp (s1, s2, C_TXTLEN) ? "Nein" : "Ja", strcmp (s1, s2) ? "Nein" : "Ja"); /* in String 1 + 2 an Stelle 7 eine 0 kopieren; zusaetzlich in * String 2 an Stelle 8 + 9 die Werte 'c' und 'k' kopieren */ *(s1 + 7) = 0; *(s2 + 7) = 0; strcpy (s2 + 8, "ck"); /* die beiden Strings unterscheiden sich jetzt an den Stellen 8 + 9: in s1 steht da "ng", in s2 "ck" */ /* zweiter Vergleich: Wenn strncmp() nicht bei 0 aufhoert, muss hier ein Ergebnis != 0 herauskommen, tatsaechlich aber ergibt das: (s1 = <ein str>) == (s2 = <ein str>)? strncmp: Ja; strcmp: Ja */ printf ("(s1 = <%s>) == (s2 = <%s>)? strncmp: %s; strcmp: %s\n", s1, s2, strncmp (s1, s2, C_TXTLEN) ? "Nein" : "Ja", strcmp (s1, s2) ? "Nein" : "Ja"); return (0); } <schnapp> Jan

Hallo, Am Sonntag, 28. Juli 2002 21:26 schrieb Jan Trippler:

On Sam, 27 Jul 2002 at 07:16 (+0200), David Haller wrote: [...]

...

static int count = 0; int hrv; char *ret; + char * use_fqdn;

hrv = gethostname (host, sizeof (host)); + + if( hrv == 0 && ! ( (use_fqdn = getenv("EVOLUTION_MSGID_FQDN")) != NULL + && strncmp(use_fqdn, "no\0", 3) == 0) ) {

[...]

Nur mal so am Rande: Welchen Sinn hat es hier, strncmp() statt schlicht strcmp(use_fqdn, "no") zu nutzen? strncmp() vergleicht auch nur _höchstens_ 3 Byte, maximal aber bis zum ersten Null-Byte. In welchem Fall also sollte sich hier strncmp anders verhalten als strcmp?

Jan

Diese Antwort gehört eigentlich nach `suse-programming'. Ich verstehe nicht, welchen Sinn der String hat: "no\0", denn in C wird an einen String _immer_ ein Nullzeichen angefügt. Dann stehen da also zwei. Der Unterschied zwischen `strcmp' und `strncmp' müßte ein Integer-Vergleich sein, also etwa for (i = 0; c[ i]; ++i) gegen for (i = 0; c[ i] && i < n; ++i) oder vielleicht auch nur for (i = 0; i < n; ++i) Das kostet zwar Prozessorzeit (Subtraktion n - i), aber ich meine nicht soviel, daß es ein Anwender merkt. Gruß Bertram -- Bertram Scharpf

Am Mon, 2002-07-29 um 11.13 schrieb Bernd Brodesser:

* Bertram Scharpf schrieb am 29.Jul.2002:

...

Dann stehen da also zwei.

Der Unterschied zwischen `strcmp' und `strncmp' müßte ein Integer-Vergleich sein, also etwa

for (i = 0; c[ i]; ++i)

gegen

for (i = 0; c[ i] && i < n; ++i)

oder vielleicht auch nur

for (i = 0; i < n; ++i)

Glaube nicht, daß da eine forschleife genommen wird.

Nun, die Realität ist deutlich komplizierter: * strcmp, strncmp und strlen sind oft in hochoptimiertem ASM geschrieben. * Der generic (maschinen-unabhängige) strncmp der glibc2 verwendet 4-Byte-INT-Vergleiche für strings mit Längen > 4. Ist also damit zu rechnen, dass er bei längeren Strings ehe schneller als strcmp ist, bei kurzen Strings aber langsamer (Overhead). Bei anderen Architekturen und libc's kann das aber auch ganz anders aussehen.

Und auch nicht c[i] oder so sondern *c. etwas solche Konstrukte:

while (*a && *b && *a++ == *b++); Sicherlich nicht ;)

+a++ == *b++ hat in C nicht definiertes Verhalten. Ein Blick in den "generic" Quellcode der libc: int strcmp (p1, p2) const char *p1; const char *p2; { register const unsigned char *s1 = (const unsigned char *) p1; register const unsigned char *s2 = (const unsigned char *) p2; unsigned reg_char c1, c2; do { c1 = (unsigned char) *s1++; c2 = (unsigned char) *s2++; if (c1 == '\0') return c1 - c2; } while (c1 == c2); return c1 - c2; } Ralf

Hallo Ratti, * Ratti [24.07.02 21:53]:

Ich gucke mal, ob hier in der Liste noch was schlaues zu dem Thema kommt, und dann wende ich mich mit diesem Material noch mal an Ximian.

Der MTA Exim ist in der Lage, die Message-ID vor dem Versenden rauszuschneiden, so dass Dein Provider seine Zeile hinzufuegen kann. Postfix kann das IMHO nicht, und wie's bei Sendmail aussieht, das weiss ich nicht. Gruss, Andreas -- " Schlechte Zeugen sind Augen und Ohren fuer Menschen, wenn sie Barbarenseelen haben " [Heraklit]