stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Teleman <>
Subject Re: Soalris 10 10/2008 SPARC changes (was: Re: 4.2.2 release)
Date Mon, 17 Aug 2009 14:27:37 GMT
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.


int ret = catclose (pcat_data->catd);

// ...

cat_closed = ret == 0;

My understanding of, 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 ?

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.


Stefan Teleman

View raw message