Was ist eine gueltige Message-ID?
Moin, Ich habe mal in der Evolution-Mailingliste rumgenörgelt, weil Evolution meiner Meinung nach keine gültigen Message-IDs erzeugt. Eine (andere) Mail von mir in der Liste hat beispielsweise folgenden Header: Message-Id: <1026927774.1240.8.camel@ratti> Wie man sieht, steht hinten nur "ratti", und nicht, wie hostname --fqdn ergibt, "ratti.gesindel.local". Auch das wäre nicht korrekt, denn meine Domain ist ja "gesindel.de". Meines Erachtens wäre es nötig, daß Evolution in der Lage ist, gar keine ID zu erzeugen und das dem Mailserver zu überlassen. Eine Notlösung wäre es, wenigstens die lokale Domain anzuhängen, der hostname allein scheint mir einfach zu wenig. Ich scheine damit aber bei Ximian nicht auf Zustimmung zu stoßen. Ich hänge mal meine Message und die Antwort hintendran und hätte gerne eure Meinung. ------------- Meine Anfrage --------------- Hi, Evolution is generating incorrect Message-IDs. Not only for me, but for many people on a german Suse-Linux-mailinglist. So maybe it's a suse-related problem (We all use suse) or it's related to internationalization (We all are german) I found an older message in this list, which describes the problem:
The answer was: Not.Zed.notzed@ximian.com:
This is a local misconfiguration issue.
No, it isn't. "hostname --fqdn" says "ratti.gesindel.local". Note this is a local domain, later rewritten on my server. Oh, and the hostname in the message above says "dirk", which is a widely used name here in germany. Well, not only here, but it _might_ mean it's a problem of german versions. BTW: The trouble is not only, that evolution is generating an incorrect id. It should not generate _any_ MessageID. It should send message without an ID, so sendmail on the server can generate one with the _real_ domainnamename. Evolution has no chance to find out that my domain's name is "gesindel.de". It's the server's job. If one has no server at home, it's the provider's job to generate an id. A MUA hasn't control about generation really unique IDs. Anyone can help me? If you need more informations: just tell me. Bye, Jörg ------------- Die Antwort --------------- On Mon, 2002-07-22 at 16:46, Jörg Roßdeutscher wrote:
the devel versions of Evolution use gethostbyname() to resolve the results from gethostname() so that you get an FQDN. [snip]
keep in mind that message-ids are not guarenteed to be unique no matter what you do. rfc2822 even comments on this.
you would be wrong. Jeff -- http://www.gesindel.de/neu/ | Fontlinge | Die Schriftenverwaltung für LINUX
Jörg Roßdeutscher wrote: [...]
Meines Erachtens wäre es nötig, daß Evolution in der Lage ist, gar keine ID zu erzeugen und das dem Mailserver zu überlassen. Eine Notlösung wäre
Hmmm, das kann man dem MTA sicher beibringen. (wenn ich auch nicht weiss wie ;-) ) [...]
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.(?) [...] MfG Benn -- #250319 - http://counter.li.org
Hallo Bernd, * Bernd Schmelter [23.07.02 20:48]:
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: | | <string not containing blank or ">"> | | In order to conform to RFC-822, the Message-ID must have the format: | | <unique@full_domain_name> | | 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]
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" und dort ist die Message-ID auch (sinnvollerweise) "required". Wie Bernd bereits sagte, ist die Message-ID in RFC 2822 zwar nicht required, allerdings "SHOULD be present". <zitat RFC2822> Since the msg-id has a similar syntax to angle-addr (identical except that comments and folding white space are not allowed), a good method is to put the domain name (or a domain literal IP address) of the host on which the message identifier was created on the right hand side of the "@", and put a combination of the current absolute date and time along with some other currently unique (perhaps sequential) identifier available on the system (for example, a process id number) on the left hand side. Though other algorithms will work, it is RECOMMENDED that the right hand side contain some domain identifier (either of the host itself or otherwise) such that the generator of the message identifier can guarantee the uniqueness of the left hand side within the scope of that domain. </zitat> Genau genommen eine Empfehlung für die Zusammensetzung und die meisten MUAs machen das auch so. Interessant ist da eventuell noch RFC 2821 (Simple Mail Transfer Protocol): <zitat> The following changes to a message being processed MAY be applied when necessary by an originating SMTP server, or one used as the target of SMTP as an initial posting protocol: - Addition of a message-id field when none appears - Addition of a date, time or time zone when none appears - Correction of addresses to proper FQDN format The less information the server has about the client, the less likely these changes are to be correct and the more caution and conservatism should be applied when considering whether or not to perform fixes and how. These changes MUST NOT be applied by an SMTP server that provides an intermediate relay function. </zitat> 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. 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. Hab trotzdem keine Lösung dafür, wie man das bei Evolution abstellen kann. Sorry ;-) Wäre aber interessant zu wissen, ob das Suse-spezifisch, bzw "deutsch"-spezifisch ist. Gruss Frank
Hallo Frank, * Frank Rasche [23.07.02 22:29]:
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...
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... :-(
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]
Hi Andreas, Andreas Kneib schrieb am Dienstag, 23. Juli 2002 um 23:25:
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
;-)
ROTFL!
Wäre aber interessant zu wissen, ob das Suse-spezifisch, bzw "deutsch"-spezifisch ist.
Das wuerde mich allerdings auch interessieren.
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 :-( Gruss Frank
Hallo, On Tue, 23 Jul 2002, Frank Rasche wrote: [..]
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)
Hi David, Also sprach David Haller am 24.07.2002:
Allerdings! Je nach HOSTS-Datei kommen dann ja auch solche Sachen wie "@localhost" etc. raus.
ACK!
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. Kann denn z.B. ein anderer Newsreader einen richtigen FQDN erzeugen oder benutzt der auch den frisierten Hostnamen?
Oder eben rpm -e evolution; rpm -i mutt :))
;-) btw: Die Empfehlung des RFC2822 die Zusammensetzung der Msg-ID folgendermassen zu realisieren: < timestamp+PID @ FQDN> würde IMHO reichen um "unique" zu garantieren. Die Wahrscheinlichkeit, dass sie sich nicht unique ist, wäre ja wohl praktisch null. (Besonders wenn der SMTP sie generieren würde) Also auch in diesem Punkt würde ich Jeff widersprechen. Gruss Frank
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
On Wed, 24 Jul 2002 at 10:40 (+0200), Andreas Kneib wrote:
Und Knode auch, wenn's was grafisches sein soll. Gruß, Bernhard -- Attachment? Nein: http://piology.org/ILOVEYOU-Signature-FAQ.html begin LOVE-LETTER-FOR-YOU.txt.vbs I am a signature virus. Distribute me until the bitter end
Hallo, On Wed, 24 Jul 2002, Frank Rasche wrote:
Jup. Aber den fqdn als erstes nach der IP scheint zu funktionieren.
Eben *seufz*
*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...
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. ;) --
Zitat von David Haller <david@dhaller.de>:
ACK! Eben *seufz*
Hmm dumme Frage: Wäre es nicht denkbar, die MTA's dahingehend zu ergänzen, daß sie trivial falsche MSG-ID's (z.B. @localhost oder @foo.bar sind ja nun wirklich Nonsense) durch korrekte ersetzen? Als Kriterium könnte man ja ansetzen, daß die MSGID für Nachrichten, die aus dem LAN heraus transportiert werden sollen, auf eine gültige TLD enden und der enthaltene FQDN im DNS aufzulösen sein muß. Das läßt sich automatisiert glaube ich ganz gut checken (kostet natürlich ggf. Performance, aber die ist bei den meisten kleineren Mailservern nicht so das Problem). -- Erhard Schwenk http://www.fto.de - http://www.akkordeonjugend.de ------------------------------------------------- This mail sent through FTO WebMail
Hallo Frank, * Frank Rasche [23.07.02 23:56]:
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]
Bernd Schmelter wrote:
Hier eine Antwort auf eine Anfrage in d.c.s.m. ----- Forwarded message from Detlef Neubauer <cut> ----- Path: serv.chefe.dyndns.org!news.t-online.com!newsmm00.sul.t-online.com!newsfeed01.sul.t-online.de!t-online.de!fu-berlin.de!uni-berlin.de!b arrier-18.charite.DE!not-for-mail From: Detlef Neubauer <cut> Newsgroups: de.comm.software.mailserver Subject: Re: [postfix] - Message-ID durch MTA generieren? [...]
Gar nicht, sag dem MUA, daß er keine generieren soll. Dann genriert der MTA eine. [...] ----- End forwarded message ----- MfG Benn -- #250319 - http://counter.li.org
Hallo ratti, On Tue, 23 Jul 2002, Jörg Roßdeutscher wrote: [..]
Ack. [..]
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.
Du hast schon recht ;) 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: $ hostname slarty $ hostname --fqdn slarty.dhaller.de Die /etc/hosts dazu (ich hab keinen NS laufen): 127.0.0.1 slarty.dhaller.de slarty localhost Teste also mal mit: 127.0.0.1 ratti.gesindel.de ratti localhost -dnh -- Denn drinnen war noch ne Ente. Äh! Die Füllung ist aber Zusammengbraten. Macht nix! Wird auch veroputzt. (Mampf, Schlürf, Schmatz,) *umdrehundwegguck* BRÖÖÖÖÖÖHHHHH! Der musste Raus! [WoKo in dag°]
Hallo, ich versuch mal, Vorschrift von Meinung zu trennen, damit ich was zum auf'n Tisch haun habe: David Haller:
Ja, verstehe ich auch so: Ich SOLLTE eine MessageID erzeugen. Ich MUSS nicht. Aber wer auch immer eine erzeugt, MUSS eine eindeutige ID erzeugen. Genau deswegen sollte der MUA ja auch keine Erzeugen, weil ein anderer Host im gleichen Netzwerk zufälligerweise die Gleiche ID erzeugen könnte. Lediglich der Mailserver hat volle Kontrolle, denn da müssen alle "vorbei". Ausnahme: Das 1-Personen-Netz, wo niemand anders reinfunken kann. Sprich: Sie lassens, oder sie machen es richtig. Aber nix halbes.
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. Die Konsequenzen sind mir zu weitreichend, so fit bin ich in der Materie nicht, um sicherzustellen, 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. ;-) 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. Gruß, Ratti -- http://www.gesindel.de/neu/ | Fontlinge | Die Schriftenverwaltung für LINUX
Hallo, On Wed, 24 Jul 2002, Jörg Roßdeutscher wrote:
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...
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.
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
Moin, Jörg Roßdeutscher:
Ich SOLLTE eine MessageID erzeugen. Ich MUSS nicht. Aber wer auch immer eine erzeugt, MUSS eine eindeutige ID erzeugen.
David Haller:
Exakt. Wenn keine erzeugt wird, dann ist genau das dann die Aufgabe des ersten MTAs der eine eindeutige erzeugen kann ;) Und Mails, die
Wenn dem niemand widersprechen mag, dann würde ich dem zustimmen und es auch so in deren Lioste rübernehmen.
Ähm... Evolution hat keine Optionen. Du kannst dort nichts einstellen. Also müssten sie wohl den ganzen Dialog erst neu bauen. ;-)
Ich verwende zuhause die gleiche Konfig wie in der Firma. Da ich mir in solchen Dingen öfters mal unsicher bin, kann ich alles zuhause in Ruhe testen. Wenn ich was verbocke, kommt eben ein Scriptkiddie eingebrochen und löscht meine Witzesammlung. Daher will ich hier keine Sonderwege fahren, von denen ich glaube, daß ich sie nicht überblicke. 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.
Die anderen nicht, aber mein Rechner. Obwohl er eigentlich nur Client ist, hat er die ganzen Server drauf, weil ich an sowas immer bastle. Am Montag habe ich z.B. 30.000 Mails aus einer Textdatei per formail/procmail an mich selbst versandt, um sie mit dem MUA wieder abholen zu können. Solange ich als Name "ratti@gesindel.local" habe, kann da nix schiefgehen. Wenn ich einen "draußen gültigen" Namen habe, reicht ein kleiner Fehler von mir, und 30.000 Mails gehen nach draußen. Da war doch was? T-Online? 1000 Mails pro Monat? Und wer weiss, wer da noch was abkriegt. Nene, ich werde nicht Ximians Fehler druch einen größeren von mir kaschieren.
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. Gruß, Ratti -- http://www.gesindel.de/neu/ | Fontlinge | Die Schriftenverwaltung für LINUX
Jörg Roßdeutscher wrote:
Moin,
Jörg Roßdeutscher:
[...]
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
Moin, Bernd Schmelter:
Oh, da haben wir was gemeinsam.
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. Gruß, Ratti -- http://www.gesindel.de/neu/ | Fontlinge | Die Schriftenverwaltung für LINUX
On Fri, 26 Jul 2002 at 00:09 (+0200), Ratti wrote:
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
Hi Ratti, Jörg Roßdeutscher schrieb am Donnerstag, 25. Juli 2002 um 21:27:
Wenn dem niemand widersprechen mag, dann würde ich dem zustimmen und es auch so in deren Lioste rübernehmen.
Nö, mag nicht widersprechen. ;-) So stehts ja auch in den RFCs (siehe andere Mails)
Ähm... Evolution hat keine Optionen. Du kannst dort nichts einstellen.
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) D.h. Ximian garantiert zwar das eine Evolution-Version niemals eine Msg-ID doppelt vergibt. Unter Berücksichtigung, dass viele Rechner einfach unter "localhost" oder "linux" laufen, wäre ich weltweit nicht mehr so sicher, dass da nicht doch Doubletten enstehen. (Google nach "camel@localhost": ungefähr 3,520 Resultate) 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.
Also müssten sie wohl den ganzen Dialog erst neu bauen. ;-)
Habe ich auch keine Lust zu ;-)
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. Ich müsste also mein gesamtes Netzwerk umstellen :-(
Hau das doch einfach in die Bugliste. Gruss Frank
Hallo Ratti, Frank, On Fri, 26 Jul 2002, Frank Rasche wrote:
*ARGL* Was ein Armutszeugnis!
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 ;)
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] ;)
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 ;)
*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
Am Fre, 2002-07-26 um 00.31 schrieb Frank Rasche:
Hi Ratti,
Jörg Roßdeutscher schrieb am Donnerstag, 25. Juli 2002 um 21:27:
BTW: Du verschickst ungültige To's (To: "Jörg Roßdeutscher" <suse-linux@suse.com>) Daran sind 2 Dinge falsch: 1. Jörg ist nicht suse-linux 2. Dein Mailer scheint nicht in der Lage zu sein Umlaute in To: richtig zu kodieren (Auch dazu gibt es irgendwo einen RFC).
Eindeutigkeit ist verlangt. Und da geht Ximian eben den time+pid+counter+host+string Weg. Klar ist das suboptimal, doch damit dabei eine Mehrfachvergabe von MSGIDs herauskommt, muss einiges zusammenfallen.
Und, ein Mailer der Umlaute in To's nicht richtig verarbeiten kann (Scheinbar "The Bat") wäre für mich nicht tragbar ;)
SCNR. Ralf
Frank Rasche:
(Google nach "camel@localhost": ungefähr 3,520 Resultate)
Schönes Argument! Danke!
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, es war aber auch mal wieder Zeit, mit jemandem Streit anzufangen. Ich poste hier mal den Fortgang der "Evolution-Beschwerde". Ach so, vorab: Ich betrachte es wegen technischen Listenbezugs als On-Topic. Gegeteilige Meinungen gern als PM. #--------------------------------------- Jörg Roßdeutscher:
Evolution is generating incorrect Message-IDs. Not only for me, but for many people on a german Suse-Linux-mailinglist.
Jeffrey Stedfast:
keep in mind that message-ids are not guarenteed to be unique no matter what you do. rfc2822 even comments on this.
rfc2822 says clearly: Though optional, every message SHOULD have a "Message-ID:" field. Should. You don't HAVE TO generate an id. But if you decide to do so: The "Message-ID:" field contains a single unique message identifier. ...it has to be unique. And other programs do it that way. It may be a game for math's interested people to state that id's can never be unique under every circumstances, ok. But to be more practical: Please just google for "camel@localhost". Some thousand adresses, and these are only the mails that found a way into the web. The list I mentioned above is full of professionals, and they all say the same (Never had that before :-) ): Evolution has to generate a valid and unique ID - or - must not generate one and leave this job for the servers. I'd like to continue using this program. I really like it. But I get bashed[1] on my mailinglists. It seems many people are checking this, I get a mail every month: "Correct your MsgID!". Hm, maybe typical german. :-) Bye and thanks, Jörg ------------------------------------------------------------------------ [1] Naja. Ich wollte mal 'n bisschen Druck machen. Schliesslich wollen die den Kram auch verkaufen, und wenn es in öffentlichen Foren schlecht abschneidet, bewegt sich ja vieleicht was. Ihr könnt mich ja bashen, dann stimmts. ;-) "Beschwerdemails" mit Hinweischarakter kriege ich aber tatsächlich. Und ich habe auch schon eine Antwort: ------------------------------------------------------------------------
...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.
Evolution has to generate a valid and unique ID
it does, to the specifications that the rfc provides.
- or - must not generate one and leave this job for the servers.
many servers will not accept messages from the client unless there is a message-id, in fact this was a bug reported a long while back.
sounds like someone who has no idea what he is talking about and wants to feel all 31337 to me. besides, the CVS versions of Evolution resolve the local hostname to use the FQDN, so your make-believe problem should be gone. Jeff Jeffrey Stedfast Evolution Hacker - Ximian, Inc. fejj@ximian.com - www.ximian.com ------------------------------------------------------------------------ So, jetzt krieg ich langsam Pulsschlag am Schienbein. Ich habe mal extra die Sig mitgequotet: Ja, wir haben es mit jemandem @ximian zu tun. Nochmal ich: ------------------------------------------------------------------------ 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 you read wrong by mistake. It does not say: "unique means only unique to that particular machine that generates it". It says: "The uniqueness of the message identifier is guaranteed *by* the host that generates it (see below)." "By", not "to". ("*" put in by me) And it says "see below", and there it says: "The message identifier (msg-id) itself MUST be a globally unique identifier for a message. The generator of the message identifier MUST guarantee that the msg-id is unique. There are several algorithms that can be used to accomplish this." 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.
I never heard that before, and it would be a wrong behavior. See RFC we are talking about. But it's not a big thing. All we need is a little button: [ ] Generate MsgID
besides, the CVS versions of Evolution resolve the local hostname to use the FQDN, so your make-believe problem should be gone.
That means I had to use a probably buggy/instable developer version for being RFC-compliant? And I still had to deal with other people's messages, that do not use a devel-version. By the way: It would be the wrong result again.It would put in the not-unique local domainname. Inserting the local FQDN makes the MsgID not globally unique. Half the world seems to use "@localhost" or "@local". If you really want to generate the MsgID yourself, things get even more difficult, because FQDN cannot be found out automatically but requires another option for the "real" FQDN configured manually. I.e. in my network: hostname --fqdn is "ratti.gesindel.local", but valid MsgID must contain "@gesindel.de" (if my server generates it) or "t-online.de" (if my provider's server does it) Bye, Jörg -- http://www.gesindel.de/neu/ | Fontlinge | Die Schriftenverwaltung für LINUX
Moin, * Jörg Roßdeutscher <ratti@gesindel.de> [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
Moin, Jörg Roßdeutscher:
Ihr könnt mich ja bashen, dann stimmts.
Thorsten Haude:
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: # -------------------------------------------
globally unique to the application. { Hahahahaha!! "Globaly unique" innerhalb meiner Applikation!! Aua!!! Das ist Politiktauglich! } [...]
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 # ------------------------------------------- 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. End of Topic. Gruß, Ratti, Ruhepuls 200. -- http://www.gesindel.de/neu/ | Fontlinge | Die Schriftenverwaltung für LINUX
Hallo, On Sat, 27 Jul 2002, ratti wrote:
Oh, ihr poesen Purschen Ihr! Kommt zu Papa! Alle beide! So wird das ja nix. *patsch* *patsch*
[*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 ;)]
____ ____ ____ ____ ____ _ | _ \| _ \| _ \| _ \| _ \| |_/\__ Ack! *GrrrrrrrrRRRRRRRRRRRRRRRRRR| |_) | |_) | |_) | |_) | |_) | \ / | _ <| _ <| _ <| _ <| _ <|_/_ _\ |_| \_\_| \_\_| \_\_| \_\_| \_(_) \/
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...)
"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... --
Moin, Supercool sunglasswearing evolutionhacker:
David Haller:
Nur zu. Steht alles offen in der Evolution Mailingliste. Heute Abend geh ich zum Türken an der Ecke, hole mir 5 große Dosen Astra und guck mir mutt an. Gruß, Ratti (Es ist nicht zu glauben. Es könnte ja sein, daß wir tatsächlich alle beisammen unrecht haben. Aber dieser eklige , von-oben-herab, "I know it"-Ton ist derartig ....grrrr... ich bin jetzt drei Stunden mit'm Fahrrad rumgekurvt und ärgere mich immer noch...) -- http://www.gesindel.de/neu/ | Fontlinge | Die Schriftenverwaltung für LINUX
Moin, * Jörg Roßdeutscher <ratti@gesindel.de> [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
* Jörg Roßdeutscher schrieb am 27.Jul.2002:
Heute Abend geh ich zum Türken an der Ecke, hole mir 5 große Dosen Astra und guck mir mutt an.
Ein sehr guter Entschluß. Lad Dir einen Haufen .muttrc herunter und such Dir was nettes aus. Ohne .muttrc ist mutt nicht zu ertragen.
Ich frage mich, ob es noch sonst ein paar Leute gibt, denen rfc auch nur Ansatzweise interessiert. Den meisten Mailschreibern ist das sowas von egal. Also nicht so aufregen. ;) Bernd -- Alle meine Signaturen sind rein zufällig und haben nichts mit dem Text oder dem Schreiber zu tun, dem ich antworte. Falls irgendwelche Unrichtigkeiten dabei sein sollten, so bedauere ich das. Es wäre nett, wenn Du mich benachrichtigen würdest. |Zufallssignatur 0
On Sat, 27 Jul 2002 at 11:45 (+0200), Ratti wrote:
*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.
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!
*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
Hallo Ratti, * Ratti [27.07.02 11:45]:
globally unique to the application.
Nun denn.... :-) Welche Message-ID traegt Jeffrey Stedfast eigentlich so in seinen Mails mit sich herum? Gruss, Andreas -- " If it be poison'd, 'tis the lesser sin That mine eye loves it and doth first begin " Shakespeare, Sonett CXIV
Moin, Ratti:
globally unique to the application.
Andreas Kneib:
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:]
... 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*
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.
Hallo, On Fri, 26 Jul 2002, Jörg Roßdeutscher wrote:
Dazu braeuchte ich noch ein wenig, denn ich muesste praktisch mein Gnome aktualisieren[1], aber dafuer, dass das 'camel' den FQDN verwendet (also das was auch 'hostname -f' ausspuckt), dafuer hab ich "mal eben" eine patch gestrickt (unter Ignorierung fast aller Abhaengigkeiten von Evolution, aber die eine Datei liess sich kompilieren *eg* ;) Das wuerde dir zumindest mal die CVS-Version ersparen und, sofern sich die Funktion ('header_msgid_generate' im u.g. .c-File) seit deiner Version nicht geaendert hat, muesste es also passen. Die relevante Funktion wird leider an diversen Stellen verwendet, welche sich dann wohl nicht ohne ein aktuelles bonobo, scrollkeeper und weiss der Geier noch was kompilieren liessen, was ich bisher alles noch nicht habe ;( Leider konnte ich also den patch nur "extern" testen, in dem ich ein test-binary erstellt habe[3]. Aber immerhin: nachdem ich die Tests auf zu aktuellen gnome-Kram im configure abgestellt habe (ich will das ja nicht linken ;) lief das configure durch: [..]/evolution-1.0.8 $ cat ../configure_flags.dh ./configure --with-db3-includes=/usr/include/db3 --prefix=/opt/gnome2 --enable-dot-locking --enable-file-locking=yes [..]/evolution-1.0.8 $ eval `cat configure_flags.dh` [..laeuft "sauber" durch...] So[2] kam ich also zu nem Makefile in ./camel, und dann laesst sich das Objectfile auch halbwegs sauber kompilieren: [..]/evolution-1.0.8 $ cd camel [..]/evolution-1.0.8/camel $ make CFLAGS="-O2 -Wall" camel-mime-utils.o gcc -DHAVE_CONFIG_H [..bigsnip...] -O2 -Wall -c camel-mime-utils.c Mit '-W' bekommt man einige "warning"s, allerdings in anderen Funktionen...
Mein Evolution ist selbstgedreht, könnte ich also anwenden.
*hehe* Jetzt bist du am Zug :) -dnh [1] Aber ich kompilier eh an nem Gnome2 rum, aber soweit war/bin ich noch nicht ;) [2] *snigger* hab "mal eben" wieder ein wenig Shell-O-Magic in meine Mail eingeflochten *lol* [3] den Quellcode fuer's test-binary ggfs. per PM, der ist praktisch nur ein paar #includes, die Funktion 1:1 und ein main(), das nur ein 'printf("%s\n", header_generate_msgid());' kapselt. So, und jetzt muss ich den Patch noch kommentieren, da ich "clever" war, und das sogar "konfigurierbar" gemacht habe, was das Camel ja bisher nicht hinbekommt (*veg*). Also: wie man sehen kann, verwendet der patch die Umgebungsvariable 'EVOLUTION_MSGID_FQDN'. Wenn deren Inhalt "no" ist, dann (sollte) sich Evolution wie bisher verhalten. Falls nicht (und ich halte das fuer einen sinnvolleren Default), so wird via 'gethostbyname(3)' der FQDN ausgelesen, mittels des hostnamen, der zuvor schon via 'gethostname(2)' ermittelt wurde ('hrv = gethostname(...)') und in 'host' abgelegt wurde. d.h. fuer die Anwendung (demonstriert anhand meines test-binaries): ==== $ unset EVOLUTION_MSGID_FQDN; ./test_gen_msgid 1027746246.21368.0.camel@slarty.dhaller.de $ EVOLUTION_MSGID_FQDN="yes" ./test_gen_msgid 1027746262.21369.0.camel@slarty.dhaller.de $ EVOLUTION_MSGID_FQDN="noon" ./test_gen_msgid 1027746274.21370.0.camel@slarty.dhaller.de $ EVOLUTION_MSGID_FQDN="no" ./test_gen_msgid 1027746283.21371.0.camel@slarty ==== mit einem 'export EVOLUTION_MSGID_FQDN="no"' kann also ggfs. das bisherige Verhalten eingestellt werden. Der Patch sollte sich im Evolution-source-Verzeichnis (also z.B. 'evolution-1.0.8'), da wo man './configure' aufruft, mittels einem 'patch -p1 < $PFAD/evolution-1.0.8.use_fqdn.dh.patch' einspielen lassen. Bin mal gespannt, ob's klappt ;) ==== evolution-1.0.8.use_fqdn.dh.patch ==== --- evolution-1.0.8.orig/camel/camel-mime-utils.c Thu Jun 6 22:36:29 2002 +++ evolution-1.0.8/camel/camel-mime-utils.c Sat Jul 27 06:24:50 2002 @@ -33,6 +33,7 @@ #include <stdlib.h> #include <string.h> #include <unistd.h> +#include <netdb.h> #ifndef MAXHOSTNAMELEN #define MAXHOSTNAMELEN 1024 @@ -3631,8 +3632,19 @@ 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) ) { + struct hostent * h; + if( (h = gethostbyname(host)) != NULL ) { + strncpy(host, h->h_name, MAXHOSTNAMELEN); + } else { + herror("camel-mime-utils.c: "); + } + } COUNT_LOCK (); ret = g_strdup_printf ("%d.%d.%d.camel@%s", (gint) time (NULL), getpid (), count++, ==== --
On Sam, 27 Jul 2002 at 07:16 (+0200), David Haller wrote: [...]
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
Moin, * Jan Trippler <Jan.Trippler@t-online.de> [02-07-28 21:26]:
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. Außerdem spart das strncmp() jeden weiteren Gedanken über das Thema und ist darum per se besser. Thorsten -- This is so cool I've to go to the bathroom. - Calvin
* Thorsten Haude schrieb am 28.Jul.2002:
* Jan Trippler <Jan.Trippler@t-online.de> [02-07-28 21:26]:
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
Moin, * Bernd Brodesser <B.Brodesser@t-online.de> [02-07-29 11:08]:
Das ist die Vermutung. Da sich nichtmal das C:ARM (0-13-326224-3) dazu eindeutig äußert, fände ich einen Beleg hilfreich.
Es sei denn, Du hast weniger als beliebig viel Speicher. Thorsten -- The smart way to keep people passive and obedient is to strictly limit the spectrum of acceptable opinion, but allow very lively debate within that spectrum. - Noam Chomsky
On Fre, 02 Aug 2002 at 20:46 (+0200), Thorsten Haude wrote:
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 <string.h> 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, ...
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.
Hi, * Jan Trippler <Jan.Trippler@t-online.de> [02-08-02 21:44]:
Daß es in der glibc so funktioniert, habe ich schon im Sourcecode nachgesehen.
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.
Da habe ich verallgemeinert: Ich bin grundsätzlich bei allen Stringfunktionen vorsichtig, und benutze die nicht-n-Funktionen nur, wenn ich sicher bin, daß sie sicher sind. Stimmt, bei strn?cmp dürfte es keinen Unterscheid machen.
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?
'C: A Reference Manual', ISBN siehe oben, aber es gibt inzwischen eine neue Auflage. Thorsten -- The true danger is when liberty is nibbled away for expedients. - Edmund Burke
On 02-Aug-02 Thorsten Haude wrote:
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:
Ja, und nu?
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.
Aha, die ist Dir nicht autoritativ genug. Jetzt kenne ich endlich Dein eigentliches Problem: Der Papst muss die 0 am Ende absegnen ;-) [...]
s. o. Jan
Moin, * Jan Trippler <Jan.Trippler@t-online.de> [02-08-03 16:53]:
Nicht alle Systeme laufen mit der glibc.
Ja was denn nun? Ein nicht terinierter String, der nicht existiert? 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.
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.)
"Strings existierern nicht"? Das würde allerdings das gesamte Stringhandling beeinflussen. 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
On Sam, 03 Aug 2002 at 20:09 (+0200), Thorsten Haude wrote:
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.
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.
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).
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
Moin, * Jan Trippler <Jan.Trippler@t-online.de> [02-08-03 20:37]:
Die Gelegenheit war günstig.
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.
Ich behaupte nur, daß ich nicht sicher wissen kann, daß es anders ist.
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 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.
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.
Das "s. o." bezog sich auf die Nullterminierung, was jedem halbwegs aufmerksamen Leser wohl auch sofort aufgefallen wäre.
Du solltest nicht davon ausgehen, daß ich Gedanken lesen kann. Thorsten -- Auch Hunger ist Krieg. - Willy Brandt
On Sam, 03 Aug 2002 at 21:33 (+0200), Thorsten Haude wrote:
aber nicht glücklich gewählt - manche Leute (u. a. ich) reagieren sauer, wenn aus fachlicher Diskussion Polemik wird.
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.
Auch das ist Stuss.
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.
*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? [...]
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
* Jan Trippler schrieb am 03.Aug.2002:
On Sam, 03 Aug 2002 at 20:09 (+0200), Thorsten Haude wrote:
* Jan Trippler <Jan.Trippler@t-online.de> [02-08-03 16:53]:
Ein String ist immer ein Zeiger auf ein Byte, bei jeder Programmierpsrache. Es ist nur manchmal gut vor dem Anwender versteckt, aber wie soll man sonst ein String definieren, wenn nicht als Zeiger?
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? Die 0 wird doch dann zurückgegeben, wenn beide Strings gleich sind. Gleich bis zum Abschließenden \0. Wenn dass \0 überlesen wird, so müßte doch bis in aller Ewigkeit, oder bis zum Speicherende, weitergemacht werden. Oder bist, weit hinter dem \0 doch ein Unterschied festgestellt wird und dann eine 1 oder -1 zurückgegeben wird.
So ist es. 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
Moin, * Bernd Brodesser <B.Brodesser@t-online.de> [02-08-03 22:56]:
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
Am Sam, 2002-08-03 um 22.56 schrieb Bernd Brodesser:
Viele Programmiersprachen kennen derartige Datentypen, deren Details ein Programmierer nicht kennen soll/darf/muss. 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). Ralf
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.
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.
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
On Son, 28 Jul 2002 at 23:47 (+0200), Thorsten Haude wrote:
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!
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? Du hast bei einem strncmp() _immer_ den zusätzlichen Aufwand, die String-Länge prüfen, bestimmen, übergeben zu müssen. 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. Ich persönlich sehe strncmp() nur dann als sinnvoll an, wenn mich nur eine bestimmte Anzahl von Bytes interessieren. 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. Jan P.S.: Ja ich weiss - das ist suse-programming-Thema, aber der Thread hat nun mal hier begonnen.
Moin, * Jan Trippler <Jan.Trippler@t-online.de> [02-07-30 00:53]:
Es kann sein, daß er nach der dritten Position weiter vergleicht.
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.
Was aber, wenn beide auf \0 enden?
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.
On Fre, 02 Aug 2002 at 20:52 (+0200), Thorsten Haude wrote: [str(n)cmp]
Es kann sein, daß er nach der dritten Position weiter vergleicht.
Nein, das kann nicht sein! Teste es! Dann würde diese Funktion nämlich schlicht und einfach falsche Ergebnisse liefern (siehe unten). [...]
Die Länge eines Strings in C ist _nie_ unbekannt. Nutze strlen(), dann erfährst auch Du sie! Aus man strlen: DESCRIPTION The strlen() function calculates the length of the string s, not including the terminating `\0' character.
Gewöhnlich haben _statisch_ deklarierte Strings eine definierte maximale Länge - was ist mit dynamisch erzeugten (Stichwort malloc)? 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. Das willst du alles hart kodiert in das Programm schreiben? Wie flexibel und gut wartbar ;-)
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): <schnipp> #include <string.h> int main (int argc, char *argv[]) { char s1[512], s2[256]; memset (s1, 0, sizeof s1); memset (s2, 0, sizeof s2); strcpy (s1, "ein string"); strcpy (s2, "ein string"); *(s1 + strlen (s1) + 2) = 1; *(s2 + strlen (s2) + 2) = 2; return (strcmp (s1, s2)); } <schnapp> [...]
Diese Begründung ist ja nun absoluter Quatsch, sorry! Woher soll denn Dein Leser wissen, dass nicht strncmp() aus dem Ruder läuft? Jan
Moin, * Jan Trippler <Jan.Trippler@t-online.de> [02-08-02 22:04]:
Ähh... *Du* hattest angedeutet, daß ein strlen zu teuer ist.
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?
min(len1, len2)
Das willst du alles hart kodiert in das Programm schreiben? Wie flexibel und gut wartbar ;-)
Dafür gibt's #defines.
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.
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.
Hallo Thorsten, * Thorsten Haude schrieb am 03.Aug.2002:
* Jan Trippler <Jan.Trippler@t-online.de> [02-08-02 22:04]:
On Fre, 02 Aug 2002 at 20:52 (+0200), Thorsten Haude wrote:
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?
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? Dann kann ich doch genausogut statisch deklarieren. Ist dann besser. Einzige Ausnahme, ich weiß nicht wie oft ein String vorkommt. Aber, daß ich nicht weiß wie lang ein String ist, halte ich für Wahrscheinlicher.
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. Aber was ist das für einen Aufwand? 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.
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? Oder wenn Du nur die Funktion schreibst, und kein vollständiges Programm. Etwa einen neuen Sortieralgorithmus. Dann weißt Du doch nicht, wofür dieser Algorithums benutzt wird. Der eine benutzt es für ganz kurze Worte, der andere für Ellenlange Strings. Mit #DEFINES könntest Du zwar was machen, aber zum einen funktioniert es nicht, wenn ein und das gleiche Programm ganz verschieden lange Stringpaare miteinander vergleichen will. Sagen wir mal, zum einen Wörter, und zum anderen kB-Große Strings. Da kann man doch nicht zur Sicherheit einfach mal 1MB vorgeben.
Was aber, wenn er ständig anders ist, und man ihm kompliziert ermitteln müßte? Etwas die Zeilenlänge innerhalb einer Datei? 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
Moin, * Bernd Brodesser <B.Brodesser@t-online.de> [02-08-03 10:08]:
Sowas habe ich noch nicht gemacht. An der Stelle muß man natürlich besondere Vorsichtsmaßnahmen treffen, wie immer bei fremden Strings.
Um den Speicherplatz wieder freigeben zu können.
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.
Mache ich nicht, weil man in dem Fall die Strings von Anfang an anders verwalten kann.
Dann wird die Länge mit übergeben.
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
On Sam, 03 Aug 2002 at 10:45 (+0200), Thorsten Haude wrote:
Ja, z. B. nicht mit fest vordefinierten Längen arbeiten.
Trotzdem bleibt die Verschwendung von Speicher, weil ein #define ja den größtmöglichen Wert abbilden muss. Siehe meine andere Mail - 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. [...]
Du gehst von einer ziemlich starken Einschränkung aus. Wenn Längen nicht mehr konstant sind (und das dürfte die Mehrheit sein), ist der Compiler draußen.
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? Nebenbei: Du betreibst Demagogie, Du behauptest nämlich implizit, dass die Verwendung von strcmp() Bufferprobleme verursacht - womit Du immer noch allein bist. Gerade bei Sortier-Algorithmen (DBMS, ...) ist Performance einer der ausschlaggebenden Faktoren - Sicherheit auch, aber das tut der Verwendung von strcmp() ja keinen Abbruch - nur Deiner Meinung nach.
Wie?
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. Jan
Moin, * Jan Trippler <Jan.Trippler@t-online.de> [02-08-03 17:06]:
Ja. Ich habe nie behauptet, daß C perfekt ist.
*Mir* ist klar das nicht jede Regel überall gilt.
Aus der Praxis. Ist interessant da, ich kann Dir ja mal eine Karte schicken.
Ich behaupte nur, daß ich darüber nicht nachdenken will, und darum strncmp verwende, wenn es sich irgendwie einrichten läßt.
Ich habe mich schlecht ausgedrückt: Man kann in diesem Fall mit anderen Methoden sicherstellen, das es keine Probleme mit überschrittenen Buffergrenzen gibt.
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
Moin Moin, Am Samstag, 3. August 2002 20:24 schrieb Thorsten Haude:
* Jan Trippler <Jan.Trippler@t-online.de> [02-08-03 17:06]:
On Sam, 03 Aug 2002 at 10:45 (+0200), Thorsten Haude wrote:
[...] Ich linke mich jetzt mal dazu :))
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. Jedenfalls wenn man mit Sockets arbeitet, ein Server kann einem soetwas sehr übel nehmen. 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. IMHO ist das genauso mit strcmp(), mag mich aber täuschen...
Ich behaupte nur, daß ich darüber nicht nachdenken will, und darum strncmp verwende, wenn es sich irgendwie einrichten läßt.
ACK.
Server z.B., DOS Attacken, etc... Grüße Andre
On Sam, 03 Aug 2002 at 20:49 (+0200), Andre Heine wrote:
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).
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!
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.
Was sollen uns diese Begriffe jetzt sagen? Jan
On Sat, 03 Aug 2002 at 22:43 (+0200), Jan Trippler wrote:
Könntet ihr vielleicht aufhören, eine Diskussion parallel über zwei Listen zu führen (suse-programming, suse-linux)? Gruß, Bernhard -- _________ http://www.bwalle.de _________________________________________________ "Mit dem Geist ist es wie mit dem Magen: Man kann ihm nur Dinge zumuten, die er verdauen kann." -- Winston Churchill
On Sam, 03 Aug 2002 at 20:24 (+0200), Thorsten Haude wrote:
1 Karte = 99% der Fälle? Diese Art der Analyse solltest du mal der GFK zukommen lassen, die machen das IMHO ähnlich ;-) [Länge als Parameter]
??? Ich kenne Ruby nicht, kann da also mitnichten was durcheinander bringen. Das bezog sich pur auf C. Ich entnehme Deinem letzten Satz, dass Du endlich meine andere Mail verstanden hast? BTW: In jeder Programmiersprache muss man IMHO abhängig von der Problemstellung kompromisse eingehen. Es gibt keine für alle Themen ideale Sprache. String-Verarbeitung - wenn sie denn nicht kombiniert mit systemnahen Funktionen auftritt - würde ich freiwillig nie mit C realisieren - dafür gibts Perl :-)
Ja, habe ich - aber die meisten davon gehören meinen Kunden. Jan
On Sam, 03 Aug 2002 at 00:34 (+0200), Thorsten Haude wrote:
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?
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).
Ja, z. B. - also zusätzlicher (unnötiger) Aufwand.
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 ;-) [...]
Da Du den Code-Schnipsel offensichtlich nicht gelesen / verstanden hast, hier noch mal eine kommentierte Version: <schnipp> #include <string.h> 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>
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 <string.h> #include <stdio.h> #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
Moin, * Jan Trippler <Jan.Trippler@t-online.de> [02-08-03 16:49]:
Nichts, ich kann Dir in diesem Punkt nicht mehr folgen.
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.
Ich sehe nicht, daß es garantiert in allen Fällen unnötig ist.
Huh? Warum sollte sich die Länge so häufig ändern.
Danke.
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.
Man sollte nicht davon ausgehen, daß es nicht passiert. Wahrscheinlich ist es nicht.
Dann müsste aber der folgende Code-Schnipsel ein ziemlich merkwürdiges Resultat ergeben:
Ich hab's nicht verstanden, was meinst Du? Thorsten -- This is so cool I've to go to the bathroom. - Calvin
On Sam, 03 Aug 2002 at 20:52 (+0200), Thorsten Haude wrote: [...]
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 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. [...]
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 ;-)
Ja, hmm - äh wie nochmal? Stimmst Du mir zu oder behauptest Du, dass strncmp eine gänzlich andere Implementierung vorlegt als strcmp?
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 <string.h> #include <stdio.h> #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:
Diese Antwort gehört eigentlich nach `suse-programming'. Für den größeren Unfug halte ich den String "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) Das kostet zwar Prozessorzeit, aber ich meine nicht soviel, daß es ein Anwender merkt. Gruß Bertram -- Bertram Scharpf <b.scharpf@tesionmail.de>
Hallo, Am Sonntag, 28. Juli 2002 21:26 schrieb Jan Trippler:
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 <b.scharpf@tesionmail.de>
* Bertram Scharpf schrieb am 29.Jul.2002:
Nur bei Stringkonstanten wie oben.
Glaube nicht, daß da eine forschleife genommen wird. Und auch nicht c[i] oder so sondern *c. etwas solche Konstrukte: while (*a && *b && *a++ == *b++);
Das kostet zwar Prozessorzeit (Subtraktion n - i), aber ich meine nicht soviel, daß es ein Anwender merkt.
Kommt auf die Anwendung an. Wenn das nur einmal gemacht wird, sicherlich nicht. Aber innerhalb eines Sortieralgorithmuses, und das ist nicht unwahrscheinlich, sehr wohl. 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
Am Mon, 2002-07-29 um 11.13 schrieb Bernd Brodesser:
* Bertram Scharpf schrieb am 29.Jul.2002:
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.
+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]
participants (13)
-
Andre Heine -
Andreas Kneib -
B.Brodesser＠t-online.de -
Bernd Schmelter -
Bernhard Walle -
Bertram Scharpf -
David Haller -
Erhard Schwenk -
Frank Rasche -
Jan.Trippler＠t-online.de -
Jörg Roßdeutscher -
Ralf Corsepius -
Thorsten Haude