From b132a73f15e432eaf43310fce9196ca0c0651465 Mon Sep 17 00:00:00 2001 From: <> Date: Thu, 2 Jan 2003 05:25:50 +0000 Subject: This commit was manufactured by cvs2svn to create branch 'Release_2_1-maint'. --- tests/bounces/yahoo_09.txt | 165 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 165 insertions(+) create mode 100644 tests/bounces/yahoo_09.txt (limited to 'tests/bounces/yahoo_09.txt') diff --git a/tests/bounces/yahoo_09.txt b/tests/bounces/yahoo_09.txt new file mode 100644 index 00000000..f8067a5b --- /dev/null +++ b/tests/bounces/yahoo_09.txt @@ -0,0 +1,165 @@ +Return-Path: +Received: from mx04.mrf.mail.rcn.net ([207.172.4.53] [207.172.4.53]) + by mta01.mrf.mail.rcn.net with ESMTP + id <20020403190104.CHE29566.mta01.mrf.mail.rcn.net@mx04.mrf.mail.rcn.net>; + Wed, 3 Apr 2002 14:01:04 -0500 +Received: from milliways.osl.iu.edu ([129.79.245.239]) + by mx04.mrf.mail.rcn.net with esmtp (Exim 3.35 #5) + id 16sq0F-0005l5-00 + for david.abrahams@rcn.com; Wed, 03 Apr 2002 14:01:03 -0500 +Received: from milliways.osl.iu.edu (localhost [127.0.0.1]) + by milliways.osl.iu.edu (8.11.6/8.11.6/IUCS_2.44) with ESMTP id g33J11A07189; + Wed, 3 Apr 2002 14:01:01 -0500 +Received: from mta446.mail.yahoo.com (mta446.mail.yahoo.com [216.136.129.101]) + by milliways.osl.iu.edu (8.11.6/8.11.6/IUCS_2.44) with SMTP id g33J04A07150 + for ; Wed, 3 Apr 2002 14:00:05 -0500 +Date: Wed, 3 Apr 2002 14:00:05 -0500 +Message-Id: <200204031900.g33J04A07150@milliways.osl.iu.edu> +From: MAILER-DAEMON@yahoo.com +To: boost-admin@lists.boost.org +X-Loop: MAILER-DAEMON@yahoo.com +Subject: Delivery failure +Sender: boost-owner@lists.boost.org +Errors-To: boost-owner@lists.boost.org +X-BeenThere: boost@lists.boost.org +X-Mailman-Version: 2.0.8 +Precedence: bulk +List-Help: +List-Post: +List-Subscribe: , + +List-Id: Boost mailing list +List-Unsubscribe: , + +List-Archive: + +Message from yahoo.com. +Unable to deliver message to the following address(es). + +: +Sorry your message to hankel_o_fung@yahoo.com cannot be delivered. This account has been disabled or discontinued. + +: +Sorry your message to ultravirus2001@yahoo.com cannot be delivered. This account has been disabled or discontinued. + +--- Original message follows. + +The original message is over 5K. Message truncated. + +X-Track: 1: 100 +Return-Path: +Received: from milliways.osl.iu.edu (129.79.245.239) + by mta446.mail.yahoo.com with SMTP; 03 Apr 2002 10:59:57 -0800 (PST) +Received: from milliways.osl.iu.edu (localhost [127.0.0.1]) + by milliways.osl.iu.edu (8.11.6/8.11.6/IUCS_2.44) with ESMTP id g33HexA27227; + Wed, 3 Apr 2002 12:40:59 -0500 +Received: from smtp016.mail.yahoo.com (smtp016.mail.yahoo.com [216.136.174.113]) + by milliways.osl.iu.edu (8.11.6/8.11.6/IUCS_2.44) with SMTP id g33HcwA27186 + for ; Wed, 3 Apr 2002 12:38:58 -0500 +Received: from ppp-1-53.chel-5800-8.access.uk.tiscali.com (HELO albert) (RaoulGough@212.159.169.53 with login) + by smtp.mail.vip.sc5.yahoo.com with SMTP; 3 Apr 2002 17:38:54 -0000 +Message-ID: <001601c1db36$6da28950$0100a8c0@albert> +From: "Raoul Gough" +To: +References: <200204011702.g31H2eA04494@milliways.osl.iu.edu> +MIME-Version: 1.0 +Content-Type: text/plain; + charset="iso-8859-1" +Content-Transfer-Encoding: 7bit +X-Priority: 3 +X-MSMail-Priority: Normal +X-Mailer: Microsoft Outlook Express 6.00.2600.0000 +X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 +Subject: [boost] Re: boost::weak_ptr suggestions +Sender: boost-admin@lists.boost.org +Errors-To: boost-admin@lists.boost.org +X-BeenThere: boost@lists.boost.org +X-Mailman-Version: 2.0.8 +Precedence: bulk +Reply-To: boost@lists.boost.org +List-Help: +List-Post: +List-Subscribe: , + +List-Id: Boost mailing list +List-Unsubscribe: , + +List-Archive: +Date: Wed, 3 Apr 2002 18:37:55 +0100 + +> From: "Peter Dimov" +> To: +> Subject: Re: [boost] boost::weak_ptr suggestions +> Date: Mon, 1 Apr 2002 17:31:05 +0300 +> Organization: Multi Media Ltd. +> Reply-To: boost@lists.boost.org +> +> From: "Raoul Gough" +[snip] +> > Secondly, I believe it would be better for the get() method to throw or +> > assert when called on an invalidated pointer, instead of transparently +> > returning 0. In my opinion, there is a fundamental difference between +the +> > two states (null and invalid) which is not observable with the current +> > interface. The addition of a member function like "bool is_valid() +const;" +> > would also allow the user code to decide how to deal with an invalid +> > pointer, instead of merging the two distinct states into the one (null) +> > state. +> +> Right again. However, the primary methods of accessing a weak_ptr are (1) +> constructing a shared_ptr (which does throw) and (2) make_shared. get() +has +> been retained for efficiency but is not recommended (in multithreaded +> programs.) + +So why the difference in error semantics between the single and +multi-threaded idioms? For example, if I converted single-threaded code that +uses get() to thread-safe code using make_shared, I also get changed +semantics for the invalid pointer case. + +Incidentally, it looks like the use_count member function can determine +indirectly whether the target still exists or not. It seems a bit obscure +though, seeing as the reference count is really an implementation detail and +distinct from the concept of null/valid/invalid. + +> +> > The big advantage of considering invalid.get() an error is that code +which +> > then works without error using weak_ptr would have *exactly* unchanged +> > semantics using a plain pointer replacement. This allows (for example) a +> > debug build/release build choice between weak_ptr and T* for +> performance +> > reasons. If weak_ptr silently returns null on invalid pointers, then +> this +> > guarantee cannot be made - what would be undefined use on a plain +pointer +> is +> > not detected by the weak_ptr. +> +> Interesting point. You can write your own get() that does what you want: +> +> T * get(weak_ptr const & p) +> { +> return shared_ptr(p).get(); +> } +> +> but it's not as efficient as a throwing get(). Most people seem to prefer +> the current get() semantics, though, where 0 is returned. + +Well, I can understand that point of view as well - either the weak pointer +has a valid target object or not (in which case null or deleted doesn't +really matter). However, my use of a smart weak pointer is really as a +debugging aid, so I would like the error to be detected as soon as possible +(and distinguished from a null-pointer assertion or SEGV). Short of adding a +policy class template parameter, it would be easy to add a new member +function which does get() with severe checking - along the lines of +vector.at versus vector.operator[]. Just an idea. + +BTW, am I right in thinking that sharede_ptr always maintains an extra weak +reference counter? I mean, even if my code doesn't use weak_ptr, shared_ptr +still has to maintain the extra counter, right? That, combined with the +*** MESSAGE TRUNCATED *** + + +. -- cgit v1.2.3