Stefan Teleman wrote:
On Fri, Aug 14, 2009 at 16:24, Martin Sebor<[email protected]> 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
