From dev-return-8376-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org Mon Aug 17 23:17:23 2009 Return-Path: Delivered-To: apmail-stdcxx-dev-archive@www.apache.org Received: (qmail 61137 invoked from network); 17 Aug 2009 23:17:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 17 Aug 2009 23:17:23 -0000 Received: (qmail 93710 invoked by uid 500); 17 Aug 2009 23:17:42 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 93643 invoked by uid 500); 17 Aug 2009 23:17:42 -0000 Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@stdcxx.apache.org Delivered-To: mailing list dev@stdcxx.apache.org Received: (qmail 93633 invoked by uid 99); 17 Aug 2009 23:17:42 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Aug 2009 23:17:42 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of msebor@gmail.com designates 209.85.198.232 as permitted sender) Received: from [209.85.198.232] (HELO rv-out-0506.google.com) (209.85.198.232) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Aug 2009 23:17:32 +0000 Received: by rv-out-0506.google.com with SMTP id l9so821333rvb.23 for ; Mon, 17 Aug 2009 16:17:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=GXY99pwhHESD6VbqNwxBpVZv5BwasTSkcbd+a+dY2mM=; b=nhApzsFYe8LgALC3Btr9rrlIRXlijza7D1SPm0gGaOuQmSSxhWEWcIXzogXnC/6jUC 9JjzeBBYBhaaITqEHJy1eV7NWYl5a7QM/xKuoUtlyEWfsV5SdunP/0bWPnEYJiucV6n6 uNLt3JQOxfRCLURWmkA/4qWHKvvgC5mJ9YAuA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=eJp7sqkIcI7czwIrRUibiT4V3Tn4OQCvW69IshS9WmiVuKLVj1NK9HUcnjX1sLm2U9 4tTdcQ6tNdekFXmeuUjLzLP0QDrZezdxb1H8P2dIiNgz0vaz2tLo+oJGeEBuZLS/MImV ctnv9ZOP79B7hVhjFvCVNizjeYDF9CXkkDgec= Received: by 10.140.204.4 with SMTP id b4mr411857rvg.80.1250551032442; Mon, 17 Aug 2009 16:17:12 -0700 (PDT) Received: from localhost.localdomain (c-71-229-200-170.hsd1.co.comcast.net [71.229.200.170]) by mx.google.com with ESMTPS id g22sm29958394rvb.52.2009.08.17.16.17.09 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 17 Aug 2009 16:17:10 -0700 (PDT) Message-ID: <4A89E4F4.6010905@gmail.com> Date: Mon, 17 Aug 2009 17:17:08 -0600 From: Martin Sebor User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: dev@stdcxx.apache.org CC: Stefan Teleman Subject: Re: Soalris 10 10/2008 SPARC changes References: <4A85B875.6060609@gmail.com> <1ccb59a20908141227p1754544fl5925148b26805ac9@mail.gmail.com> <4A85C808.7060809@gmail.com> <1ccb59a20908170727p7630e92vd9353f3684fca32b@mail.gmail.com> In-Reply-To: <1ccb59a20908170727p7630e92vd9353f3684fca32b@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Stefan Teleman wrote: > On Fri, Aug 14, 2009 at 16:24, Martin Sebor wrote: >> Thanks for the heads up and the patches! I'll review apply them >> if possible/necessary before the release. >> >> I took a quick glance at a few of the diff files and I wonder if >> you could help me better understand some of the changes in case >> they could be applied unconditionally. >> >> For instance, in ctype.cpp.38.diff, it seems as though the second >> hunk would be a good change to make regardless (when long long is >> available). Ditto for the third hunk in locale_body.37.diff (minus >> the pragmas, of course), and similarly in locale_classic.40.diff >> and messages.cpp.41.diff. >> >> The approach I'm thinking of using is the one you applied in >> use_facet.h, i.e., defining, say, _RWSTD_ALIGN_MAX_T to unsigned >> long long, and using it in all the aligned buffers, along with >> unsigned char for the data. >> >> Other than these, can you also help me understand the changes in >> messages.cpp.41.diff (starting with the third hunk on line 92)? > > That's my bad mistake -- i created a diff for src/messages.cpp from an > older version of messages.cpp (hacked while i was trying to figure out > why it was misbehaving so badly on 32-bit SPARCv8). > > I updated the tarball and the messages.cpp.41.diff itself with a valid > patch now. Sorry for the noise. No problem. I'll take a look. > > About > > int ret = catclose (pcat_data->catd); > > // ... > > cat_closed = ret == 0; > > My understanding of 22.2.7.1.2, p5 (catalog must be valid) is that -- > if catclose(3C) fails, it means the catalog was not valid -- therefore > the C++ library must throw. So, cat_closed is now true if and only if > catclose(3C) succeeded. Or is this too restrictive ? You're right that we should check the value returned from catclose(). I think the facet guarantees that the catalog descriptor is valid so I think we're safe in that regard. The case where I think there is a problem is when catclose() fails because of a signal (with EINTR). That would make __rw_catclose() and the facet dtor leak the catd. Let me see about fixing that. Thanks for pointing it out! > > About the other patches -- and whether or not they should be applied > for other platforms besides Solaris/SPARC: i tried not to disturb any > other ISA's/compiler combinations. If you'd like i can re-write the > patches for 4.2.2 using the more generic approach you described. Understood. Thanks again! Martin > > --Stefan >