Re: prototype of the "expected failures" enhancement (STDCXX-683)

[Mark Brown]

Martin,

Most of the links to the log files are broken. They all point to files
in http://people.apache.org/tmp/. Also, I'm not sure I understand how
rows in the tables are supposed to be arranged now. If I recall, they
used to be ordered alphabetically but after your change 26 comes
before 23, and 23 before 27. Is that intended?

2   26.class.gslice 46230   162
5   23.deque.special61465   1536
7   27_basic_ios0   1

-- Mark

On Dec 31, 2007 6:38 PM, Martin Sebor <[EMAIL PROTECTED]> wrote:
> The commit below implements an initial prototype of the "expected
> failures" enhancement described in STDCXX-683. The prototype can
> be viewed on the usual test result page:
>http://people.apache.org/~sebor/stdcxx/results/builds
>
> http://svn.apache.org/viewvc?rev=607788&view=rev
>
> The new file, etc/config/xfail.txt, is intended to contain a list
> of known failures in the test suite (including examples and locales).
> The comments in the file explain how to make a failure in a component
> as expected.
>
> Let me know what you all think: questions, suggestions for changes,
> or bug reports are all welcome!
>
> Happy new year!
> Martin
>
> PS I've tested the changes with build logs on most platforms but I
> forgot to include Windows. As usual, things are different there and
> the results aren't quite satisfactory. I'll work on fixing those as
> soon as I get a chance.
>

Re: _RWSTD_VER value on trunk

[Mark Brown]

Have you considered what it's going to mean for merges between branches?
Wouldn't letting the Makefile figure out the version from the pathname of one
of the files be more reliable? If Subversion is like CVS and understands the
$Source$ keyword you could even use it.

-- Mark

On Dec 13, 2007 2:24 PM, Martin Sebor <[EMAIL PROTECTED]> wrote:
> Andrew Black wrote:
> > Martin Sebor wrote:
> >> This has been bugging me -- when someone checks out trunk, does a build and
> >> sends
> >> us build results, we have no way of telling that the build results are, in
> >> fact, for trunk and
> >> not for 4.2.0 (or the head of 4.2.x), because the value of _RWSTD_VER is 
> >> the
> >> same. I
> >> think we should change it so that the value is unique for each branch, or 
> >> at
> >> least distinct
> >> from any release.
> >>
> >> Any suggestions for what would be a good value?
> >
> > The following is my suggestion for a scheme for _RWSTD_VER:
> > Trunk: 0x
> > Trunk feature branch: 0xFFxx
> > Major branch: 0xMMFF
> > Maintenance branch: 0xMMmmFF00
>
> Thanks, this is an interesting idea that I hadn't thought of.
> At first I didn't think 0xFF made sense but I'm slowly starting
> to warm up to it.
>
> >
> > A trunk feature branch is a branch in subversion used for developing a
> > specific feature, which isn't ready for inclusion in trunk, but is major
> > enough that incremental testing is required.  An example could be the
> > implementation of concepts.  The placeholder 'xx' is a non-FF value,
> > unique to a feature branch.  If the number of feature branches exceeds
> > 255, it will be necessary to reuse numbers, but this isn't a likely
> > occurrence in the near term.  These numbers should be issued in the
> > order the branches are created.
>
> We'd have to find a way to avoid conflicts. I.e., How would one go
> about finding the next available value of xx to grab for their new
> feature branch? (It wouldn't be too hard to do today but if we had
> as many feature branches as gcc, as unlikely as it is, it could be
> a challenge.)
>
> >
> > A major branch is a branch in subversion used for ongoing development of
> > a source compatible lineage.  The placeholder MM represents the major
> > version.  An example would be ongoing maintenance of the 4.x version of
> > stdcxx beyond 4.3, after the 5.0 release has been made.  In the case of
> > a 4.x maintenance branch, the version would be 0x04FF
>
> Makes sense.
>
> >
> > Maintenance branches are an established concept, with the 4.2.x branch
> > being an example.  The placeholder MM represents the major version, with
> > the placeholder mm representing the minor version.  In the case of
> > 4.2.x, the version would be 0x0402FF00.
>
> Same here.
>
> >
> > Justification:
> > My primary reason for using the 0xFF value as a placeholder (generally)
> > is because it is greater than any particular released version number.
> > This should allow checks which look for a specific version of the
> > library (either older or newer) to function correctly.  If someone
> > wanted to exclude the trunk from these checks, it would be possible to
> > simply perform a bitwise negation, and if the value of that negation is
> > 0, it means the token references a trunk version.
>
> I think I like this idea quite a bit, actually Using a fixed value
> also makes it easy to test for it in release scripts and catch
> releases where the macro isn't set correctly (because the value
> would either be 0xFF or fail to match the version in the name of
> the tag).
>
> Is everyone else happy with this scheme?
>
> Martin
>

Re: [RFC] stdcxx release process, second draft

[Mark Brown]

The Linux Documentation Project lists a number of examples of library
incompatibilities:
http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN135

--Mark

On Dec 13, 2007 4:44 PM, Martin Sebor <[EMAIL PROTECTED]> wrote:
> Travis Vitek wrote:
> >
> >
> >> Travis Vitek wrote
> >>
> >> Martin Sebor wrote:
> >>> I've incorporated everyone's feedback and committed an updated
> >>> version with a number of enhancements of my own. Among the most
> >>> important are the new Goals section with suggested frequencies of
> >>> releases, and the integration of the Version Policy (I plan to delete
> >>> versions.html). Let me know what you think.
> >>>
> >>> http://incubator.apache.org/stdcxx/releases.html
> >>>
> >> Martin,
> >>
> >> I found this page that documents a few do's and dont's of binary
> >> compatibility. I realize that most of the tricky issues involve inline
> >> functions or templates, but this gives a list of the common pitfalls.
> >>
> >>  http://tinyurl.com/2gf38p
> >>
> >> Travis
> >
> > Here are some examples that I came up with. Each case is written in a
> > pseudo diff format.
>
> Excellent! See my comments below.
>
> >
> > Travis
> >
> >  // neither source nor binary compatible. not source compatible
> >  // if user might take address of member function A::f.
> >  struct A
> >  {
> > -int f() const { return 1; }
> > +int f(int i = 1) const { return i; }
> >  };
> >
> >  // alternative is source and binary compatible. can be changed
> >  // to a default argument in next source incompatible release.
> >  struct A
> >  {
> > int f() const { return 1; }
> > +   int f(int i) const { return i; }
> >  };
> >
> >  // is binary compatible, but not be source compatible because
> >  // the compiler has no way to handle A().f(1)
> >  struct A
> >  {
> > int f(long i) const { return 2; }
> > +   int f(unsigned i) const { return 2; }
> >  };
> >
>
> I would tend to throw these in the bag of "obvious no-no's."
>
> >  // not binary compatible, changing access specifier on windows is a
> > no-no. if the
> >  // new access modifier is more restricted, this may be source
> > incompatible, but
> >  // only if the user code calls or takes the address of the function.
> >  class A
> >  {
> > -private:
> > +public:
> >  int f() const { return 1; }
> >  };
>
> This one is much less obvious and so it might be worth mentioning
> in the document.
>
> >
> >  // source and binary compatible, not functionally compatible. f() will
> > square v
> >  // in user code, and ctor will square v in library code. if an instance
> > is
> >  // created in library and passed to user code, it will be squared
> > twice. if the
> >  // other way, it will not be squared at all.
> >  //
> >  // if the definitions were outlined, this would be compatible.
> >  class A
> >  {
> >  public:
> > -A(float f) : v(f) { }
> > -float f() const { return v*v; }
> > +A(float f) : v(f*f) { }
> > +float f() const { return v; }
> >  private:
> >  float v;
> >  };
>
> This is an interesting case. Why (when) does it matter that the result
> of f() is different? What does it mean for STDCXX-226?
>
> >
> >
> >  // binary and source compatible, but not functionally compatible
> >  // because call to g() is inlined.
> >  //
> >  // this would be compatible if f() were outlined, or g() behaved
> >  // the same for input values 2 and 3.
> >  struct A
> >  {
> > -void f() { g(2); }
> > +void f() { g(3); }
> >  void g(int i);
> >  };
>
> Same as above.
>
> >
> >
> >  // it appears that this could be fully compatible in some cases.
> >  // it might not be source/functionally compatible if the user is
> >  // exposed to this type. a switch on an E instance might cause a
> >  // default block to be hit, which could trigger a failure in user
> >  // code.
> >  //
> >  // if A::Z is used as a `last enum' marker, this might introduce
> >  // a binary compatibility issue if a global or member array is
> >  // declared to have A::Z elements.
> >  //
> >  // this might also be binary incompatible if the enum is persisted.
> >  struct A
> >  {
> > -enum E { W, X, Z };
> > +enum E { W, X, Y, Z };
> >  };
>
> I'd say this is both source and binary incompatible.
>
> Consider:
>
>switch (e) {
>case A::Z: break;
>case 4:break;   // okay in version 1 but error on version 2
>}
>
> and:
>
>template  struct S { };
>
>void foo (S());   // ==> mangled as foo_S_A_2 in version 1
>// but foo_S_A_3 in version 2
>
> Thanks again. These are exactly the kind of examples I was hoping for:
> innocuous looking changes that are fully compatible in most situations
> but can be actually be breaking in some edge cases.
>
> Martin
>

Re: question on the examples for the source/forward/backward incompatible changes

[Mark Brown]

Martin Sebor wrote:

Mark Brown wrote:
[...]

Or adding overloads with different behavior to functions that are
a better match for calls in existing programs. For instance, if we
added an overload for the ostream inserter for wchar_t* that did
something different than print the value of the pointer it would
break programs that insert wchar_t pointers into narrow streams.
So code like this: std::cout << L"insert a pointer"; inserts the
address of the wide string today, but if we added the overload it
would write the string itself.


This is an interesting example because it doesn't actually break
programs at compile time but rather changes their runtime behavior,
something that typically is associated with binary compatibility.
Incidentally, we even have an enhancement request for this new
inserter (maybe you've seen it):
http://issues.apache.org/jira/browse/STDCXX-296

But there certainly are cases where adding an overload can break
programs by introducing an ambiguity where there previously was
none.


True. And even adding a new function can break source if its name
happens to be the same as the name of some user-defined function.
Namespaces are supposed to help prevent this but they cannot help
with member functions. For instance, adding the member function
data() to std::vector will break a class that derives from vector
and that calls a global function called data.

--Mark

Re: question on the examples for the source/forward/backward incompatible changes

[Mark Brown]

Martin Sebor wrote:

Farid Zaripov wrote:

  Whether these examples should be abstract, or based on C++ Standard
Library
declarations/definitions?


Examples using the C++ standard library classes or functions would
be great, but any other sort will, in my opinion, work just as well.
The point is to highlight the general kind of changes people might
easily think are compatible when in reality they're not.



  Since the source  incompatible changes involves changes in
function/class mebmers
prototype, or changes in global data/class data members declaration, or
changing the
place of the some declaration (i.e. moving the declaration from one
header file to the another),
but requirements of the all of this are stated in C++ Standard and,
accordingly, any of these
changes are impossible.


Let me give one example where this isn't true. The standard leaves
it up to each implementation to decide whether to define overloads
of certain functions or whether to make use of default function
arguments. For instance, vector::resize() can be declared in one
of two ways:

resize(size_type, value_type = value_type());

or

resize(size_type);
resize(size_type, value_type);

Changing from one form to the other is detectable and might qualify
as a breaking change. First, programs that explicitly instantiate
vector on a user-defined type that's not default constructible will
compile with the first declaration but not with the second (because
the definition of the first overload must default-construct the
element). Second, programs that take the address of such functions
will not compile. The standard leaves the exact type of library
member functions unspecified so it's up to us whether we want to
go a step beyond and provide a stronger guarantee or not.


Or adding overloads with different behavior to functions that are
a better match for calls in existing programs. For instance, if we
added an overload for the ostream inserter for wchar_t* that did
something different than print the value of the pointer it would
break programs that insert wchar_t pointers into narrow streams.
So code like this: std::cout << L"insert a pointer"; inserts the
address of the wide string today, but if we added the overload it
would write the string itself.

--Mark

Re: STDCXX-635 and iterator validitty after deque::swap()

[Mark Brown]

Martin Sebor wrote:

Following up on an old thread...

I suspect this problem that we've been discussing for some time now
might stem from the fact that the standard doesn't actually define
what it means to invalidate an iterator. Here's some background: 
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#278


IIUC, the resolution of the issue makes the test case for the issue 
(STDCXX-635) invalid (and the behavior of deque::swap() valid WRT

repointing the end iterators).

But, unless I'm missing something, it also means that an operation
that is required not to invalidate existing iterators might actually
cause some valid iterators to point to different elements than they
did before. And that doesn't seem quite right to me.

Thoughts?


This is a tricky problem. I found an old thread on comp.std.c++
that discusses the same issue in the context of list splicing:
http://groups.google.com/group/comp.std.c++/browse_thread/thread/a9c7fe6b37f5926d/611b0e71f9e0ad6f
I haven't read the whole long thread very carefully but from what
have read it doesn't look like the group reached a firm conclusion
on the subject. I do agree that the standard absolutely must make
it clear that not just individual iterators but also ranges denoted
by pairs of iterators remain valid after non-invalidating operations
or not.

--Mark



Martin


Farid Zaripov wrote:

-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Monday, July 09, 2007 7:40 AM
To: stdcxx-dev@incubator.apache.org
Subject: Re: 23.deque.special

Farid Zaripov wrote:
  Below is a part of the 23.deque.special test. These rw_assert's 
fails because of deque::end() internal representation is 

dependent on

object and cannot be swapped.

I'm not sure I understand.


  The std::deque<>::iterator type has two members: pointer to the
current element and pointer
to the array containing the element (include/deque, line 188):

// `cur' points at the curent element or is null (for the end
iterator)
// `node' points to the array containing the element or &cur (for
end)
pointer _C_cur;
_C_node_pointer _C_node;
};

  For the end iterator _C_node == &_C_cur.

  In case swapping two empty deque, two end iterators being swapped.

  Let's iter1 is the iterator of some deque1 and iter2 is the iterator
of another deque2 before swap.
And let's iter3 is the iterator of deque1 and iter4 is the iterator of
deque2 after swap.

Before swap:

  iter1._C_cur == 0;
  iter1._C_node == &deque1._C_end._C_cur;

  iter2._C_cur == 0;
  iter2._C_node == &deque2._C_end._C_cur;

After swap still:

  iter3._C_cur == 0;
  iter3._C_node == &deque1._C_end._C_cur;

  iter4._C_cur == 0;
  iter4._C_node == &deque2._C_end._C_cur;

The iterators mebmer values aren't swapped, because if they would
swapped these iterators
wouldn't be "end iterators" in terms of our deque implementation.

  iter3 != iter2 and iter4 != iter1

So in our deque implementation we shouldn't compare end iterators after
swap operation.


Swapping two deques is required not to invalidate any iterators, isn't

that right?

  If iter3 should == iter2 and iter4 should == iter1, then we need to
change the deque implementation.


Are you suggesting to loosen the test so as not to exercise this

requirement?
  I suggest only not to exercise iterators if one deque is empty.

Farid.

Re: Apache C++ Standard Library 4.2.0 released

[Mark Brown]

Farid Zaripov wrote:

-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, October 31, 2007 6:35 PM

To: stdcxx-dev@incubator.apache.org
Subject: Re: Apache C++ Standard Library 4.2.0 released


FYI: I've made the same announcement on a number of 
newsgroups and mailing lists:


Farid, it would be great if you could translate it 
to Russian and spread the word in your neck of the woods.


  Ok. I'll post the announce to the C++ forum on the
Russian Development Network (www.rsdn.ru).


I gather this is it: http://www.rsdn.ru/forum/message/2721871.1.aspx



  But I'm not sure that translation is needed, because I sure that
the all russian-speaking programmers are able to understand this
announcement (like any other techical documentation).


Unfortunately, not all English-speaking programmers can read Russian
;-) Looks like they found the string performance graph interesting.
Was there any useful feedback?

--Mark



Farid.

Re: [RFC] build result views

[Mark Brown]

Have you guys seen the Boost regression test page?
http://engineering.meta-comm.com/boost-regression/1_34_1/user/summary_release.html
I think there are some good ideas there. I like the links to
the test sources and to the compiler errors for the ones that
error out.

--Mark

Martin Sebor wrote:

Farid Zaripov wrote:

-Original Message-
From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin Sebor
Sent: Tuesday, November 13, 2007 6:18 AM
To: stdcxx-dev@incubator.apache.org
Subject: [RFC] build result views

I'm looking for feedback on the two sets of nightly result pages we 
currently publish:


   http://people.apache.org/~sebor/stdcxx/results/

and

   http://people.apache.org/~sebor/stdcxx/results/builds

Specifically, I'm wondering what would people think about replacing 
the first page with the second, or something like it. Do you find 
yourself using the first page more or do you prefer the second one, 
and why?


  The first page is useful to see the overall status of the library.
I'm using it just for sure that Windows builds are green :)


:) That's how I've been using it too. The danger of colorizing
entire builds the way we do on that page is in making it easy
to miss important failures occurring only in a small number of
tests. I.e., you might see green even when a critical piece of
the library is broken (recall the recent binary incompatibility
with XLC++ exception).

Anyway, sounds like adding colorization either to builds.html
or to the Logs and Columns table on each Multi-platform Test
Result View is one enhancement you'd like to see, correct?

What about data? Do you use any of the data from the colorized
page? E.g., the number of components (examples, tests, locales)
vs the number of those that failed? I personally don't think
they are terribly useful but adding them shouldn't be too hard.
I do plan on adding the duration column (with a lot more detail,
such as how long the library took to build in user, system, and
wall clock time, and the same for all examples, the test driver,
tests, and locales). Anything else?



  Of cource the second page is more convinient to see what
examples or tests are failed and how these fails dependent
from the build type.

  I would like to have the possibility to merge the results of the
multiple platforms into the one page, i.e.:
- all windows builds (MSVC and ICC);
- all MSVC builds;
- all ICC/windows builds;
- all ICC builds (windows and linux);
- all MSVC 8.0 build + all gcc 4.2.0 builds;


This is something I'd like to be able to do as well, and I have
in a small number of cases. It can easily be done by changing
the genxviews script to generate whatever combination of builds
you need (we should move the data out of the script to make it
possible to do this without modifying the script itself).

After making the changes you just run your custom genxviews like
this:

  $ genxviews > $HOME/public_html/stdcxx/results/builds.html

Of course, the ultimate implementation would let you do it on
demand (e.g., as you suggest below).

One thing to keep in mind is that the more builds you squeeze on
a page the harder it becomes to see them all at the same time. At
a certain point it starts to defeat the purpose of the page because
you end up scrolling it left and right to see the results for all
the platforms.


...

  It might be realized as the current page
(http://people.apache.org/~sebor/stdcxx/results/builds)
but with the checkboxes on the each line of the table and button
"Next" somewhere on the page.


That would be pretty cool. The only thing is that generating the
pages takes quite a bit of time (you can see how long in the Time
column), so you might have to wait a few minutes to get the results
for a custom selection. We could probably optimize it to just a few
seconds by pre-processing the individual logs so as not to make the
script work so hard.

Martin



If neither, how do you analyze build results and why do you find your 
system preferable to what we have? What does your ideal result page 
look like? What data should it show and how should it be presented?


Farid.

Re: [Fwd: ASF Board Meeting Summary - November 14, 2007]

[Mark Brown]

Woohoo! This is awesome news! Congratulations!

--Mark


William A. Rowe, Jr. wrote:

Congratulations from your mentors, Justin and I, well done guys!

 Original Message 
Subject: ASF Board Meeting Summary - November 14, 2007
Date: Thu, 15 Nov 2007 10:34:54 -0500
From: Jim Jagielski <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]

The ASF board had their monthly meeting yesterday, in a nice
but echo-y room (Thanks to Concom for arranging the room)
here at ApacheCon US in Atlanta. It was held face-to-face with
all directors physically present.

At the meeting we voted on 2 resolutions, both of which
handily passed. As a result, we have 2 new TLPs:

  o The Apache C++ Standard Library Project
 - Incubator graduation
 - Martin Sebor PMC Chair

  o The Apache HttpComponents Project
 - Jakarta "graduation"
 - Erik Abele PMC Chair

Congrats to the PMCs and chairs.

Re: question on the examples for the source/forward/backward incompatible changes

[Mark Brown]

Farid Zaripov wrote:

  Whether these examples should be abstract, or based on C++ Standard
Library
declarations/definitions?

  Since the source  incompatible changes involves changes in
function/class mebmers
prototype, or changes in global data/class data members declaration, or
changing the
place of the some declaration (i.e. moving the declaration from one
header file to the another),
but requirements of the all of this are stated in C++ Standard and,
accordingly, any of these
changes are impossible.


Hi Farid,

I believe the standard leaves some details unspecified so library
writers can decide how to implement them. For instance, default
arguments and overloads.

--Mark



Farid.

another istream_iterator question

[Mark Brown]

I have been looking at the istream_iterator class, mostly out of
curiosity than to try to fix a specific bug, to see if there are
any other discrepancies with the standard and operator++ caught
my attention. The standard says that the operator should return
*in_stream >> value but the stdcxx definition looks like this:

istream_iterator& operator++ () {
return _C_strm && !!*_C_strm && (*_C_strm >> _C_val), *this;
}

There are two extra checks that aren't required by the standard.
They are probably harmless but I wonder if they shouldn't be
removed for efficiency. Does anyone see a problem with such
a change?

--Mark

Re: stream iterators into different streams compare equal?

[Mark Brown]

Travis asked me to forward his response (thanks for the confirmation,
Travis!) to the list. I suppose I should open an issue for this then.

--Mark

[EMAIL PROTECTED] wrote:

mark.g.brown wrote:

Hi all,

I have the simple program below that aborts with the latest stdcxx but
runs with no problems with g++. Am I missing something or is this a
bug in stdcxx?

#include 
#include 
#include 

int main ()
{
std::istringstream a ("1");
std::istream_iterator i (a);

std::istringstream b ("2");
std::istream_iterator j (b);

assert (!(i == j));
}

--Mark


24.5 p3 says

Two end-of-stream iterators are always equal. An end-of-stream iterator is not 
equal to a non-end-of-stream iterator. Two non-end-of-stream iterators are 
equal when they are constructed from the same stream.

24.5.1.1 p1 says

istream_iterator () Effects: Constructs the end-of-stream iterator.

24.5.1.1 p2 says

istream_iterator(istream_type& s) Effects: Initializes in_stream with s. value 
may be initialized during construction or the first time it is referenced.

24.5.1.2 p6 says

template <...> bool operator=(const istream_iterator<...> &x, const 
istream_iterator<...> &y) Returns (x.in_stream == y.in_stream) [assuming in_stream is a pointer 
to the stream the iterator references].

Given 24.5.1.1 p1 and p2, it is pretty clear to me that the two iterators are 
both non-end-of-stream type, and they are both created on different streams. 
The streams are different, so the iterators should not compare equal. I guess 
one could claim that 24.5.1.2 p6 conflicts with 24.5 p3 because 'end-of-stream' 
isn't clearly defined, but in this particular case that doesn't matter.

Travis

stream iterators into different streams compare equal?

[Mark Brown]

Hi all,

I have the simple program below that aborts with the latest stdcxx but
runs with no problems with g++. Am I missing something or is this a
bug in stdcxx?

#include 
#include 
#include 

int main ()
{
std::istringstream a ("1");
std::istream_iterator i (a);

std::istringstream b ("2");
std::istream_iterator j (b);

assert (!(i == j));
}

--Mark

Re: [VOTE] release stdcxx 4.2.0 (candidate 7)

[Mark Brown]

Other than some warnings gcc 4.1.2 on Linux worked fine this time.
I tried Intel 10.0 and found another test that gave a compiler error.
I didn't investigate it in great detail but it looks like a problem
in the test rather than a compiler bug. In any event, I don't see it
as a blocker for the release and change my vote to +1. Hopefully we
can fix it in 4.2.1.

/home/mbrown/stdcxx-4.2.0/tests/regress/26.valarray.transcend.stdcxx-315.cpp(43): 
error: implicitly generated assignment operator cannot copy:

const member "S::self"
  struct S {
 ^
  detected during:
implicit generation of "S &S::operator=(const S &)" at line 
1033 of "/home/mbrown/stdcxx-4.2.0/include/valarray"
instantiation of "std::valarray<_TypeT> std::abs(const 
std::valarray<_TypeT> &) [with _TypeT=S]" at line 78


--Mark

Martin Sebor wrote:

I just created the next stdcxx 4.2.0 release candidate tag,
stdcxx-4.2.0-rc-7, that incorporates changes addressing issues
pointed out in the original vote thread.
http://svn.apache.org/repos/asf/incubator/stdcxx/tags/4.2.0-rc-7/

The tarball containing the release candidate sources can be
downloaded from my home directory at the following link:
http://people.apache.org/~sebor/stdcxx-4.2.0-rc-7/stdcxx-incubating-4.2.0.tar.gz 



The MD5 sum for the tarball is: b43adeb0c72cf4747301818f4dff4fa1

Instructions on unpacking the tarball, configuring and building
the library and the set of examples and tests, are in the README
file contained in the tarball and can also be viewed directly
in Subversion:
http://svn.apache.org/repos/asf/incubator/stdcxx/tags/4.2.0-rc-7/README

The Jira "Release Notes" for 4.2.0 detailing the issues resolved
in this release can be viewed here:
http://tinyurl.com/ytzonz

stdcxx 4.2.0 has been tested on the set of platforms listed in
the README. The test results for most of the tested platforms
can be be viewed on the following page:
http://people.apache.org/~sebor/stdcxx-4.2.0-rc-7/results/
(there are a few failures, most of them attributable to issues in
the Rogue Wave test infrastructure; a small number of failures are
due to known stdcxx issues).

Please download and test the tarball and vote to approve the
release and to request the approval of the Incubator PMC to publish
it on the stdcxx site. In your vote, please include the names and
versions of the compilers and operating systems that you tested on.

As always, everyone is encouraged to vote, including non-committers.

This vote will close in the usual 72 hours from now, i.e., on
Tuesday, 10/23 at 5:00 PM US/Mountain time. Follow the link
below for the countdown:
http://tinyurl.com/2h5f73

Re: Problem building stdcxx-4.2.0-rc7 on Solaris

[Mark Brown]

Martin Sebor wrote:


[snip]

Here are a few possibilities:

1. Clean slate. Everything compiles and links cleanly with no
   errors or warnings, and runs successfully to completion with
   zero failed assertions.

2. Warnings acceptable, no errors. Same as above except that
   warnings are allowed. (How many warnings? I.e., what's the
   threshold?)

3. Warnings and some failed assertions acceptable. Just like (2)
   except that tests are allowed to report some failed assertions.
   (Again, how many failed assertions are acceptable?)

4. Status quo. I.e., some warnings are acceptable, compilation
   or linker errors (except in the library) are acceptable if
   they are attributable to platform bugs or limitations, some
   (small number) of runtime errors, including abnormal exits,
   are expected.

Ideally, we'd shoot for (1). Frankly, I don't see it happening
without a monumental effort. I'm not even convinced that (2) is
doable. Maybe (3), with a lot of work. I agree that (4) is less
than optimal.

Thoughts?


I think #2 should be the goal on common platforms although I can
appreciate that enforcing the rule in rare environments could be
hard. I suppose it's up to us to decide what the "common" target
platforms are. In my opinion, Linux should definitely be one.
Windows another. Solaris is also pretty widely available. Others?

-- Mark

[jira] Commented: (STDCXX-231) std::getline from header is rather slow

[Mark Brown (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12537089
 ] 

Mark Brown commented on STDCXX-231:
---

I just benchmarked getline() from stdcxx 4.1.3 against the same function in gcc 
4.1 (the program is below), and out of curiosity against the wc utility on 
Linux. stdcxx is more than twice slower than gcc, and nearly ten times slower 
than wc.The timings for a 32MB text file are:

$ ls -l input.txt && time LD_LIBRARY_PATH=../lib ./getline 1 input.txt && time 
./a.out 1 input.txt && time wc -l input.txt && cat getline.cpp
-rw-rw-r-- 1 mbrown mbrown 32942720 Oct 23 11:30 input.txt
892370

real0m0.433s
user0m0.400s
sys 0m0.036s
892370

real0m0.149s
user0m0.124s
sys 0m0.024s
892370 input.txt

real0m0.053s
user0m0.048s
sys 0m0.004s
#include 
#include 
#include 
#include 

int main (int argc, char *argv[])
{
unsigned long loops;
const char* file;

loops = 1 < argc ? strtoul (argv [1], 0, 0) : 1;
file =  2 < argc ? argv [2] : __FILE__;

unsigned long line_count = 0;
std::string line;

for (unsigned long i = 0; i != loops; ++i) {
std::ifstream in (file);
if (!in.is_open ())
return 1;

while (std::getline (in, line))
++line_count;
}

printf ("%lu\n", line_count);
}


> std::getline from  header is rather slow
> 
>
> Key: STDCXX-231
> URL: https://issues.apache.org/jira/browse/STDCXX-231
> Project: C++ Standard Library
>  Issue Type: Improvement
>  Components: 21. Strings
>Reporter: Martin Sebor
>
> Moved from the Rogue Wave bug tracking database:
> Created By: leroy @ Jan 25, 2001 03:20:01 PM
> Environment
>   Compiler : SUNPRO 4.2
>   OS : Solaris 2.5.1
>   SCL : 1.3.0 (Summer-1999)
>   Tools : 7.1.0 (Summer-1999) --> Use only for RWBench
> Command line option :
>   for debug : 
>   CC -xildoff +w +p -g -o Test_dbg.exe test.cc -DRWDEBUG=1 
> -I/opt/RogueWave/Summer-1999/workspaces/SOLARIS251/SUNPRO42/11s 
> -I/opt/RogueWave/Summer-1999/workspaces/SOLARIS251/SUNPRO42/11s/include -I. 
> -L/opt/RogueWave/Summer-1999/workspaces/SOLARIS251/SUNPRO42/11s/lib -Bstatic 
> -ltls11s -lstd11s -Bdynamic
>   for release :
> CC -xildoff +w +p -fast -o Test_release.exe test.cc 
> -I/opt/RogueWave/Summer-1999/workspaces/SOLARIS251/SUNPRO42/8s 
> -I/opt/RogueWave/Summer-1999/workspaces/SOLARIS251/SUNPRO42/8s/include -I. 
> -L/opt/RogueWave/Summer-1999/workspaces/SOLARIS251/SUNPRO42/8s/lib -Bstatic 
> -ltls8s -lstd8s -Bdynamic
>  (Uploaded file: 997149-test.cc)  
>   
>   
>   
>   
>  
>  Entered By: Web @ Thursday, January 25, 2001 2:41:42 AM  
> Location of uploaded file: 
> http://thoth.bco.roguewave.com/uploads/997149-test.cc
> View all uploaded files for this incident: 
> http://webdev.roguewave.com/admin/tsvw/index.cfm?IncidentID=997149
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
>   
> 
>  Entered By: Web @ Thursday, January 25, 2001 2:44:56 AM  
> #web
> Please find my test case at the end of the note
> Environment
>   Compiler : SUNPRO 4.2
>   OS : Solaris 2.5.1
>   SCL : 1.3.0 (Summer-1999

Re: [VOTE] release stdcxx 4.2.0

[Mark Brown]

Martin Sebor wrote:

I created what I'm hoping will be the final stdcxx 4.2.0 release
candidate, stdcxx-4.2.0-rc-6:
http://svn.apache.org/repos/asf/incubator/stdcxx/tags/4.2.0-rc-6/

along with a tarball containing the sources:
http://people.apache.org/~sebor/stdcxx/stdcxx-incubating-4.2.0.tar.gz

The MD5 sum for the tarball is: f65ea507f7d82688d1cf241bce25dc01

Instructions on unpacking the tarball, configuring the library,
and building it along with the set of examples and tests, are
in the README file contained in the tarball. The file can also
be viewed directly in Subversion:
http://svn.apache.org/repos/asf/incubator/stdcxx/tags/4.2.0-rc-6/README

The Jira "Release Notes" for 4.2.0 detailing the vast number of
issues resolved in this release can be found here:
http://tinyurl.com/ytzonz

stdcxx 4.2.0 has been tested on the set of platforms listed in
the README. The test results for most of the tested platforms
can be be viewed on the following page:
http://people.apache.org/~sebor/stdcxx/results/
(there are some failures, most of them due to the Rogue Wave test
infrastructure and IT issues; please disregard those).

Please take the tarball for a spin and vote to approve the release
and to request the approval of the Incubator PMC to publish it on
our site.

Everyone is encouraged to vote, including non-committers.

This vote will close in the usual 72 hours.


+0, mainly because not all tests compiled.

I confirmed that the binary compatibility issue with limits has
been resolved in 12D and 11D buildtypes. Great job you guys!

Compiling the library with gcc 4.1.2 with optimization on is clean
with the exception of the two warnings below. This is a regression
from 4.1.3 which is free of these warnings. I also saw a number
of the same warnings in the examples and the test driver. I don't
know much about strict aliasing to judge if the warnings indicate
actual problems or if they are safe to ignore. Either way, I don't
necessarily see them as a reason to hold up the release. There
also are many warnings about not being able inline some functions.

Besides the warnings, the test 26.valarray.cassign.cpp gave many
compiler errors (see the attached log file) All other tests and
examples compiled okay, although many with warnings. I don't know
the stdcxx policy regarding compiler errors in tests but if the
test compilation errors are a known issue (STDCXX-512?) we might
want to disable the test in 4.2.0.

--Mark

/home/mbrown/stdcxx-4.2.0/src/ctype.cpp: In constructor 
‘std::ctype_byname::ctype_byname(const char*, long unsigned int)’:
/home/mbrown/stdcxx-4.2.0/src/ctype.cpp:944: warning: dereferencing 
type-punned pointer will break strict-aliasing rules


/home/mbrown/stdcxx-4.2.0/include/rw/_rawiter.h: In function ‘void 
std::return_temporary_buffer(_TypeT*) [with _TypeT = 
std::ios_base::_C_usr_data::_C_event_cb]’:

/home/mbrown/stdcxx-4.2.0/src/iostore.cpp:151:   instantiated from here
/home/mbrown/stdcxx-4.2.0/include/rw/_rawiter.h:164: warning: 
dereferencing type-punned pointer will break strict-aliasing rules
/home/mbrown/stdcxx-4.2.0/include/rw/_rawiter.h: In function 
‘std::pair<_TypeT*, _Distance> std::get_temporary_buffer(_Distance, 
_TypeT*) [with _TypeT = std::ios_base::_C_usr_data::_C_event_cb, 
_Distance = long int]’:
/home/mbrown/stdcxx-4.2.0/include/rw/_rawiter.h:153:   instantiated from 
‘std::pair<_TypeT*, long int> std::get_temporary_buffer(long int) [with 
_TypeT = std::ios_base::_C_usr_data::_C_event_cb]’

/home/mbrown/stdcxx-4.2.0/src/iostore.cpp:120:   instantiated from here
/home/mbrown/stdcxx-4.2.0/include/rw/_rawiter.h:138: warning: 
dereferencing type-punned pointer will break strict-aliasing rules

g

Re: stdcxx 4.2.0/4.1.3 binary incompatibility on Linux

[Mark Brown]

On 10/17/07, Travis Vitek <[EMAIL PROTECTED]> wrote:
>
> So the problem is that the size of the __string_ref has changed, right?
> Specifically, this block of code causes the removal of the per-string
> mutex from __string_ref.
>
> +#ifndef _RWSTD_NO_ATOMIC_OPS
> +   // disable string mutex when atomic operations are available
> +#  ifndef _RWSTD_NO_STRING_MUTEX
> +#define _RWSTD_NO_STRING_MUTEX
> +#  endif   // _RWSTD_NO_STRING_MUTEX
> +#endif   // _RWSTD_NO_ATOMIC_OPS
>
> An obvious option would be to just remove that block and let the user
> decide if they want to define _RWSTD_NO_STRING_MUTEX or not. If they
> define it then they must know that they are breaking binary
> compatibility with a library previously compiled without it. This
> doesn't help users compiling new source using the default configuration,
> but it does maintain compatibility.

This would be the safe way of handling it: maintain compatibility
while giving users a simple way to build a faster but incompatible
library. Given how hard it seems to be to debug problems caused by the
incompatibility I think this is a most sensible approach.

>
> We could also ask that they define _RWSTD_NO_ATOMIC_OPS, but that may
> cause other binary incompatibilities elsewhere or it will at the very
> least cause performance problems in other places.

Making the fast (but incompatible) implementation the default would
certainly make new users happy but expose existing users who are
upgrading from previous releases to the dire consequences of the
incompatibility. Which group is more important to us?

-- Mark

>
> It would be nice if we could just insert an appropriately sized pad
> buffer in place of the _C_mutex member. If the methods of __string_ref
> were not inlined I'm pretty sure that this would work. Unfortunately
> _C_inc_ref() and _C_dec_ref() are inlined, so their code may be compiled
> in the user executable, so I'm not convinced that this is a viable
> option.
>
> Travis
>
>
> Martin Sebor wrote:
> >
> >Okay, I've got it:
> >
> >http://issues.apache.org/jira/browse/STDCXX-162
> >
> >Damn that was hard!
> >
> >So, what do we do? Going back to using a mutex for strings would
> >be *huge* performance hit on one of the most popular platforms
> >(if not the most popular one), but then again, keeping the status
> >quo will break binary compatibility on the (now) most popular
> >platform.
> >
> >Opinions?
> >
> >Martin
> >
> >Martin Sebor wrote:
> >> Martin Sebor wrote:
> >>> In a 12D build with the default gcc 4.1.0 on SuSE Linux Enterprise
> >>> Server 10 (x86_64), the following simple program abends with the
> >>> error below after upgrading the 4.1.3 library to 4.2.0:
> >>
> >> I've enhanced the program to replace operators new and delete
> >> and to print the value of the pointer. The enhanced test case
> >> and the output obtained from a 12D build with gcc 3.4.6 on Red
> >> Hat Enterprise Linux AS release 4 (Nahant Update 4) is below.
> >> Interestingly, the 12d (32-bit) output with Sun C++ on Solaris
> >> is fine.
> >>
> >> $ cat t.cpp && LD_LIBRARY_PATH=../lib ./t
> >> #include 
> >> #include 
> >> #include 
> >> #include 
> >>
> >> int main ()
> >> {
> >> std::string s = "a";
> >> }
> >>
> >> void* operator new (std::size_t n) throw (std::bad_alloc)
> >> {
> >> void* const p = std::malloc (n);
> >> std::fprintf (stdout, "operator new (%zu) ==> %#p\n", n, p);
> >> return p;
> >> }
> >>
> >> void operator delete (void *p) throw ()
> >> {
> >> std::fprintf (stdout, "operator delete (%#p)\n", p);
> >> std::free (p);
> >> }
> >>
> >> void* operator new[] (std::size_t n) throw (std::bad_alloc)
> >> {
> >> void* const p = std::malloc (n);
> >> std::fprintf (stdout, "operator new[] (%zu) ==> %#p\n", n, p);
> >> return p;
> >> }
> >>
> >> void operator delete[] (void *p) throw ()
> >> {
> >> std::fprintf (stdout, "operator delete[] (%#p)\n", p);
> >> std::free (p);
> >> }
> >>
> >> operator new (58) ==> 0x502010
> >> operator delete (0x501fe8)
> >> *** glibc detected *** free(): invalid pointer:
> >0x00501fe8 ***
> >> Aborted
> >>
> >>
> >
>

Re: stdcxx 4.2.0/4.1.3 binary incompatibility on Linux

[Mark Brown]

On 10/17/07, Martin Sebor <[EMAIL PROTECTED]> wrote:
> Okay, I've got it:
>
> http://issues.apache.org/jira/browse/STDCXX-162
>
> Damn that was hard!
>
> So, what do we do? Going back to using a mutex for strings would
> be *huge* performance hit on one of the most popular platforms
> (if not the most popular one), but then again, keeping the status
> quo will break binary compatibility on the (now) most popular
> platform.
>
> Opinions?

Maybe it isn't as bad as you think. Have you done any measurements of
the performance difference between the previous version and 4.2.0?

-- Mark

Re: 4.2.0-rc-6, final candidate

[Mark Brown]

Martin Sebor wrote:

After dispatching the remaining issues scheduled for 4.2.0(*) I'd
like to merge the few outstanding minor fixes and docs changes to
4.2.0 and create the (hopefully) final release candidate at the
end of the day (US/Mountain) tomorrow. If anyone has any concerns
please raise them ASAP.

[*] Here's a list of the remaining issues to deal with:
http://tinyurl.com/2g7hv8

Andrew and Farid, you each have an issue on the list assigned to
you. Please try to resolve them before the end of business tomorrow.
I'll take care of the rest (I'll need to spend some time reworking
the patch for STDCXX-509 so that it's binary compatible. If I can
fix STDCXX-406 and STDCXX-302 in isolation from other platforms
I will, otherwise I'll defer it to 4.2.1 with the effect of
Compaq/HP C++ not being supported on Tru64 in 4.2.0).



Regarding binary compatibility, after upgrading from 4.1.3 to
the latest 4.2.0 I'm getting invalid pointer errors from glibc
in some of my programs. I reproduced the same error in the
except example in 4.1.3. Unfortunately, I don't have time to
debug it right now.

-- Mark

$ LD_LIBRARY_PATH=../lib ./except
*** glibc detected *** ./except: munmap_chunk(): invalid pointer: 
0x00602110 ***

=== Backtrace: =
/lib64/libc.so.6(cfree+0x1b6)[0x3571a72c56]
../lib/libstd15D.so(_ZN4__rw15__rw_eofbit_setD0Ev+0x39)[0x2ab072dd]
./except(__gxx_personality_v0+0x2a0)[0x4010c0]
/lib64/libc.so.6(__libc_start_main+0xf4)[0x3571a1d8a4]
./except(__gxx_personality_v0+0xe9)[0x400f09]
=== Memory map: 
0040-00402000 r-xp  08:02 22415427 
 /home/mbrown/stdcxx-4.1.3-gcc-4.1.2-15D/examples/except
00601000-00602000 rw-p 1000 08:02 22415427 
 /home/mbrown/stdcxx-4.1.3-gcc-4.1.2-15D/examples/except
00602000-00623000 rw-p 00602000 00:00 0 
 [heap]
357160-357161a000 r-xp  08:02 17006839 
 /lib64/ld-2.5.so
3571819000-357181a000 r--p 00019000 08:02 17006839 
 /lib64/ld-2.5.so
357181a000-357181b000 rw-p 0001a000 08:02 17006839 
 /lib64/ld-2.5.so
3571a0-3571b46000 r-xp  08:02 17006871 
 /lib64/libc-2.5.so
3571b46000-3571d46000 ---p 00146000 08:02 17006871 
 /lib64/libc-2.5.so
3571d46000-3571d4a000 r--p 00146000 08:02 17006871 
 /lib64/libc-2.5.so
3571d4a000-3571d4b000 rw-p 0014a000 08:02 17006871 
 /lib64/libc-2.5.so

3571d4b000-3571d5 rw-p 3571d4b000 00:00 0
3571e0-3571e82000 r-xp  08:02 17006891 
 /lib64/libm-2.5.so
3571e82000-3572081000 ---p 00082000 08:02 17006891 
 /lib64/libm-2.5.so
3572081000-3572082000 r--p 00081000 08:02 17006891 
 /lib64/libm-2.5.so
3572082000-3572083000 rw-p 00082000 08:02 17006891 
 /lib64/libm-2.5.so
3574a0-3574a15000 r-xp  08:02 17006887 
 /lib64/libpthread-2.5.so
3574a15000-3574c14000 ---p 00015000 08:02 17006887 
 /lib64/libpthread-2.5.so
3574c14000-3574c15000 r--p 00014000 08:02 17006887 
 /lib64/libpthread-2.5.so
3574c15000-3574c16000 rw-p 00015000 08:02 17006887 
 /lib64/libpthread-2.5.so

3574c16000-3574c1a000 rw-p 3574c16000 00:00 0
357ec0-357ec0d000 r-xp  08:02 17006830 
 /lib64/libgcc_s-4.1.2-20070626.so.1
357ec0d000-357ee0d000 ---p d000 08:02 17006830 
 /lib64/libgcc_s-4.1.2-20070626.so.1
357ee0d000-357ee0e000 rw-p d000 08:02 17006830 
 /lib64/libgcc_s-4.1.2-20070626.so.1

2aaab000-2aaad000 rw-p 2aaab000 00:00 0
2aaad000-2abbc000 r-xp  08:02 22414809 
 /home/mbrown/stdcxx-4.2.0-gcc-4.1.2-15D/lib/libstd15D.so.4.2.0
2abbc000-2adbb000 ---p 0010f000 08:02 22414809 
 /home/mbrown/stdcxx-4.2.0-gcc-4.1.2-15D/lib/libstd15D.so.4.2.0
2adbb000-2adc5000 rw-p 0010e000 08:02 22414809 
 /home/mbrown/stdcxx-4.2.0-gcc-4.1.2-15D/lib/libstd15D.so.4.2.0

2adc5000-2addc000 rw-p 2adc5000 00:00 0
2adf7000-2adfb000 rw-p 2adf7000 00:00 0
7fff6350a000-7fff6351f000 rwxp 7fff6350a000 00:00 0 
 [stack]
ff60-ffe0 ---p  00:00 0 
 [vdso]

Aborted

Re: relative pathnames in ChangeLogs

[Mark Brown]

Martin,

This sounds reasonable to me. Although I wonder, is there any reason
to have a number of ChangeLogs instead of just one at the top of the
tree?

-- Mark

Martin Sebor wrote:

After I generated/updated the latest ChangeLogs I noticed that we have
been less than completely consistent in how we refer to changed files
in Change Log entries. Most of the time, although not all of the time,
we just mention the file name w/o the directory prefix. That's not a
big deal when all the files in the ChangeLog entry reside in the same
directory (although even then it's less than ideal), but it becomes
a potential problem when there are files from different directories,
e.g., include/foo.h and src/bar.h, because there may be a src/foo.h
in addition to include/foo.h.

To avoid this potential problem I would like to propose that each file
mentioned in a Change Log entry be relative to the directory containing
the ChangeLog itself. I.e., file names referenced in the ChangeLog
residing under trunk/include/ will be relative to trunk/include/, those
reference in the ChangeLog residing under trunk/tests will be relative
to trunk/tests, and so on.

For example, the ChangeLog entry for the following change:
  http://svn.apache.org/viewvc?view=rev&revision=583398
would look like so:

2007-10-10 Travis Vitek <[EMAIL PROTECTED]>

STDCXX-582
* self/0.printf.cpp (test_errno): Deallocate memory allocated
automatically by rw_snprintfa().

Change Log entries that refer to files from multiple subdirectories
(e.g., trunk/include and trunk/examples) would have to also include
the name of the subdirectories.

Does this sound reasonable to everyone? Does anyone have a better idea?

Martin

[jira] Created: (STDCXX-544) use gcc __builtin functions

[Mark Brown (JIRA)]

use gcc __builtin functions
---

 Key: STDCXX-544
 URL: https://issues.apache.org/jira/browse/STDCXX-544
 Project: C++ Standard Library
  Issue Type: Improvement
  Components: Build
Affects Versions: 4.1.3
 Environment: gcc
Reporter: Mark Brown


Gcc provides many built-in equivalents of C library functions like memcpy or 
strlen for optimization purposes. stdcxx should take advantage of them when 
possible to deliver better performance.

http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Other-Builtins.html#Other-Builtins

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Exec utility test group reporting

[Mark Brown]

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Mon, 27 Aug 2007 09:11:51 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: Exec utility test group reporting
> 
> Greetings Mark
> 
> At this point, the validity, usability and accuracy of the Doxygen
> comments in the exec utility is a theoretical exercise, as I don't think
> anyone's ever taken the step of generating the documentation pages from
> the source files.  That said, I've installed doxygen locally, and will
> share the results if I have time to play with it.

Well, I tried generating documentation for the stdcxx/util directory to see how 
Doxygen does. The result is published on my home page: 
http://mark.g.brown.googlepages.com/stdcxxutil. This is my first attempt to use 
the site so pardon the appearance of the entry page. In my opinion, it doesn't 
look half bad, don't you think?

> 
> It would likely make sense to eventually store the generated docs
> somewhere in subversion, but the potential problem of documentation
> drift exists.  I suppose this shouldn't count as a strike against using
> Doxygen, as that potential exists for all documentation.

Would generating the documentation automatically be a solution?

-- Mark

> 
> --Andrew Black
> 
> Mark Brown wrote:
>> Hi Andrew,
>> 
>> I found myself needing documentation for the test driver in the past.
>> Since  you mentioned Doxygen comments in the exec utility, I'm wondering
>> if there is generated documentation available somewhere that I don't
>> know about. Could you point me in the right direction?
>> 
>> Many thanks!
>> -- Mark
>> 
>> 
>>> -Original Message-
>>> From: [EMAIL PROTECTED]
>>> Sent: Thu, 23 Aug 2007 11:48:26 -0600
>>> To: stdcxx-dev@incubator.apache.org
>>> Subject: Exec utility test group reporting
>>> 
>>> Greetings all.
>>> 
>>> Attached is a patch that aims to add some logic to the exec utility to
>>> report the type of executable being processed.  Part of the purpose of
>>> this change is to assist in making the result parsing more robust.
>>> 
>>> I am not particularly satisfied with this change for a couple reasons.
>>> One is because the doxygen comments are getting out of date, and need
>>> to
>>> be gone over.  The second is the way data is passed from cmdopt.cpp to
>>> display.cpp.  The current method used is to overload the target_opts
>>> struct to include the new parameter, but this feels like the wrong way
>>> to do things.  This method was chosen because the verbose flag is
>>> currently included there, but the exec subsystem shouldn't care about
>>> either of these things.  (The verbose output mode also feels like it
>>> was
>>> hacked on, but that's irrelevant to this topic.)
>>> 
>>> Does anyone have thoughts on this patch?  I should note that some
>>> changes to the windows infrastructure will be needed to keep the
>>> behavior in sync with the unix infrastructure.
>>> 
>>> --Andrew Black
>> 
>> 
>> KEEP SPYWARE OFF YOUR COMPUTER - Protect your computer with Spyware
>> Terminator!
>> Visit http://www.spywareterminator.com/install and find out more!


FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your 
desktop!
Check it out at http://www.inbox.com/marineaquarium

Fwd: Re: svn commit: r564059 - in /incubator/stdcxx/trunk: include/limits src/limits_bits.cpp

[Mark Brown]

For some reason this post bounced. It's probably my fault for using two
email accounts. I should use the same one.

-- Mark

-- Forwarded message --
From: mark.g.brown <[EMAIL PROTECTED]>
Date: Aug 14, 2007 11:09 PM
Subject: Re: Re: svn commit: r564059 - in /incubator/stdcxx/trunk:
include/limits src/limits_bits.cpp
To: stdcxx-dev@incubator.apache.org

Martin Sebor wrote:
> Andrew Black wrote:
>> Greetings Martin
>>
>> I'm not completely certain, but I believe this change is leading to
>> failures on most or all operating systems.  In particular, linker
>> warnings of
>
> Drat! The patch is incomplete. I forgot to commit a change
> to another library file that forward declares the symbol.
> This should fix it:
> http://svn.apache.org/viewvc?view=rev&rev=564664

I'm curious, is this change meant to be binary compatible? I ask because
some of my programs have started to fail to link since I updated to the
latest stdcxx sources.

-- Mark

>
> Thanks for letting me know!
> Martin
>
>>> ld: (Warning) Unsatisfied symbol "__rw::__rw_flt_infinity" in file
>>> $(BUILDDIR)/lib/libstd.sl
>>> ld: (Warning) Unsatisfied symbol "__rw::__rw_dbl_infinity" in file
>>> $(BUILDDIR)/lib/libstd.sl
>>> ld: (Warning) Unsatisfied symbol "__rw::__rw_ldbl_infinity" in file
>>> $(BUILDDIR)/lib/libstd.sl
>> are observed in static builds (on HPUX), and the same message is
>> observed when running the exec utility in dynamic builds.
>>
>> --Andrew Black
>>
>> [EMAIL PROTECTED] wrote:
>>> Author: sebor
>>> Date: Wed Aug  8 17:47:54 2007
>>> New Revision: 564059
>>>
>>> URL: http://svn.apache.org/viewvc?view=rev&rev=564059
>>> Log:
>>> 2007-08-09  Martin Sebor  <[EMAIL PROTECTED]>
>>>
>>> STDCXX-509
>>> * limits (__rw_flt_denorm_min, __rw_flt_infinity, __rw_flt_qNaN,
>>> __rw_flt_sNaN, __rw_dbl_denorm_min, __rw_dbl_infinity,
>>> __rw_dbl_qNaN,
>>> __rw_dbl_sNaN, __rw_ldbl_denorm_min, __rw_ldbl_infinity,
>>> __rw_ldbl_qNaN,
>>> __rw_ldbl_sNaN): Declared floating point constants with "C" language
>>> linkage to prevent "clever" compilers such as MSVC from mangling
>>> their
>>> type into their names and to permit them to be defined with
>>> different
>>> types.
>>> * limits_bits.cpp (__rw_flt_denorm_min, __rw_flt_infinity,
>>> __rw_flt_qNaN, __rw_flt_sNaN, __rw_dbl_denorm_min,
>>> __rw_dbl_infinity,
>>> __rw_dbl_qNaN, __rw_dbl_sNaN, __rw_ldbl_denorm_min,
>>> __rw_ldbl_infinity,
>>> __rw_ldbl_qNaN, __rw_ldbl_sNaN): Defined as statically (i.e., at
>>> load
>>> time as opposed to dynamically, at runtime) initialized unions,
>>> backed
>>> by the appropriate byte patterns, with "C" language linkage to
>>> permit
>>> the defintions to have a different type than the declarations.
>>> (__rw_flt_denorm_min_bits, __rw_flt_infinity_bits,
>>> __rw_flt_qNaN_bits,
>>> __rw_flt_sNaN_bits, __rw_dbl_denorm_min_bits,
>>> __rw_dbl_infinity_bits,
>>> __rw_dbl_qNaN_bits, __rw_dbl_sNaN_bits, __rw_ldbl_denorm_min_bits,
>>> __rw_ldbl_infinity_bits, __rw_ldbl_qNaN_bits,  __rw_ldbl_sNaN_bits):
>>> Removed.
>>>
>>> Modified:
>>> incubator/stdcxx/trunk/include/limits
>>> incubator/stdcxx/trunk/src/limits_bits.cpp
>>>
>>> Modified: incubator/stdcxx/trunk/include/limits
>>> URL:
>>>
http://svn.apache.org/viewvc/incubator/stdcxx/trunk/include/limits?view=diff&rev=564059&r1=564058&r2=564059
>>>
>>>
==
>>>
>>> --- incubator/stdcxx/trunk/include/limits (original)
>>> +++ incubator/stdcxx/trunk/include/limits Wed Aug  8 17:47:54 2007
>>> @@ -23,7 +23,7 @@
>>>   * implied.   See  the License  for  the  specific language  governing
>>>   * permissions and limitations under the License.
>>>   *
>>> - * Copyright 1994-2006 Rogue Wave Software.
>>> + * Copyright 1994-2007 Rogue Wave Software, Inc.
>>>   *
>>>
**/
>>>
>>>
>>> @@ -86,7 +86,9 @@
>>>  #endif   // _RWSTD_IS_IEC559
>>>
>>>
>>> -_RWSTD_NAMESPACE (__rw) { +_RWSTD_NAMESPACE (__rw) {
>>> +
>>> +extern "C" {
>>>
>>>  _RWSTD_EXPORT extern const float   __rw_flt_infinity;
>>>  _RWSTD_EXPORT extern const double  __rw_dbl_infinity;
>>> @@ -108,6 +110,8 @@
>>>  _RWSTD_EXPORT extern const long double __rw_ldbl_denorm_min;
>>>
>>>  #endif   // _RWSTD_NO_LONG_DOUBLE
>>> +
>>> +}   // extern "C"
>>>
>>>  }   // namespace __rw
>>>
>>>
>>> Modified: incubator/stdcxx/trunk/src/limits_bits.cpp
>>> URL:
>>>
http://svn.apache.org/viewvc/incubator/stdcxx/trunk/src/limits_bits.cpp?view=diff&rev=564059&r1=564058&r2=564059
>>>
>>>
==
>>>
>>> --- incubator/stdcxx/trunk/src/limits_bits.cpp (original)
>>> +++ incubator/stdcxx/trunk/src/limits_bits.cpp Wed Aug  8 17:47:54 2007
>>> @@ -22,7 +22,7 @@
>>>   * implied.   See  the License  for  the  specific language  governing
>>>   * permissions and limitations under t

RE: [RFC] draft stdcxx resolution for the Board

[Mark Brown]

Martin,

I am quite certain that "Apache ServiceMix" in the resolution should read 
"Apache C++ Standard Library."

   NOW, THEREFORE, BE IT FURTHER RESOLVED, that Martin Sebor be
   appointed to the office of Vice President, Apache ServiceMix,
  ^

   to serve in accordance with and subject to the direction of
   the Board of Directors and the Bylaws of the Foundation until
   death, resignation, retirement, removal or disqualification,
   or until a successor is appointed; and be it further

-- Mark

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Mon, 27 Aug 2007 14:59:15 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: [RFC] draft stdcxx resolution for the Board
> 
> I'm working on the Board resolution based on the following page:
> 
> http://incubator.apache.org/guides/graduation.html#tlp-resolution
> 
> and I have a few issues I need help with. I'm hoping that our
> mentors can give us guidance here, although I certainly encourage
> everyone else, most of all committers, to read through this and
> provide feedback.
> 
> 
> 1. Official project name: Apache C++ Standard Library
> 
> I have always assumed that the official name of our project is
> the Apache C++ Standard Library, and that STDCXX is an "acronym"
> or "keyword" (e.g., the same way APR is to the Apache Portable
> Runtime Project). I'm not 100% sure that everyone shares the
> same view so I'm looking for a confirmation that "Apache C++
> Standard Library" is an acceptable name to use in the resolution.
> (The attached proposed resolution assumes the answer is
> affirmative.)
> 
> 
> 2. Composition of the initial PMC.
> 
> At the moment, our index page lists 11, and soon hopefully 13
> committers, plus 3 mentors (see
> http://incubator.apache.org/stdcxx/#committers):
> 
>1. Andrew Black(PPMC member)
>2. Heidi Buelow(PPMC member, Emeritus)
>3. Lance Diduck
>4. John Hollis (Emeritus)
>5. Amit Jindal (PPMC member)
>6. Liviu Nicoara   (PPMC member)
>7. Ravi Palepu     (Emeritus)
>8. Anton Pevtsov   (PPMC member)
>9. Martin Sebor(PPMC member)
>   10. Tim Triemstra   (PPMC member)
>   11. Farid Zaripov   (PPMC member)
>   12. Mark Brown  (pending IPMC approval)
>   13. Eric Lemings(pending IPMC approval)
>   14. Ben Laurie  (Mentor)
>   15. William Rowe, Jr.   (Mentor)
>   16. Justin Erenkrantz   (Mentor)
> 
> First, I'm sure everyone agrees with me that Bill and Justin have
> been a great help and that it would be a privilege to have both
> of you on the PMC. The question is, busy as I'm sure you are, do
> either of you wish not to be on it? (The attached proposed
> resolution assumes the answer is no, i.e., both Bill and Justin
> are on the PMC -- please speak up if that's not the case.)
> 
> Second, I assume that in general, the entire podling's PPMC
> becomes the (proposed) PMC by default. The question I have about
> our PPMC is: do PMC members who are in the status of Emeritus
> fall into the same category? (The attached proposed resolution
> assumes the answer is yes.)
> 
> Finally, the attached proposed resolution assumes that the IPMC
> approves both Brad and Mark as the new committers. I intend to
> wait to submit the proposal until the IMPC vote on their commit
> access has closed. If anyone thinks we should not wait please
> speak up.
> 
> 
> 3. Vice President (PMC Chair?)
> 
> The Board resolution must nominate a Vice President for top level
> projects. First, is this the same thing as the PMC Chair (see the
> definition below)? Second, we need to nominate someone for this
> office. Unless someone would like to volunteer for this post or
> unless we need to go through a formal vote process, I would be
> happy to volunteer for the office. (The attached proposed
> resolution has my name in that role.)
> 
> http://apache.org/foundation/how-it-works.html#pmc-chair
> 
> Thanks
> Martin

Re: svn commit: r569152 - /incubator/stdcxx/branches/4.2.0/etc/config/src/LIMITS.cpp

[Mark Brown]

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Sun, 26 Aug 2007 17:37:02 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: svn commit: r569152 -
> /incubator/stdcxx/branches/4.2.0/etc/config/src/LIMITS.cpp
> 
> Mark Brown wrote:
>>> -Original Message-
>>> From: [EMAIL PROTECTED]
>>> Sent: Fri, 24 Aug 2007 09:29:36 -0600
>>> To: stdcxx-dev@incubator.apache.org
>>> Subject: Re: svn commit: r569152 -
>>> /incubator/stdcxx/branches/4.2.0/etc/config/src/LIMITS.cpp
>>> 
>>> Andrew, please be sure to observe the 78 characters/line limit
>>> in Change Log entries as documented in bullet (3) of the Patch
>>> Format section on the Bugs page:
>>>http://incubator.apache.org/stdcxx/bugs.html#patch_format
>>> 
>>> The reason for this limit in both ChangeLogs and source files
>>> is that they all need to be readable on traditional VT100 text
>>> terminals.
>> 
>> I have seen coding styles with a 79 character limit (for instance
>> Python) but I am curious what the rationale for the 78 character limit
>> is when even the VT100 displays have 80 columns?
> 
> Opening a file with 80 characters per line in emacs with a buffer
> width set to 80 columns will wrap the last character of the next
> line. So if all you have to work with is an 80x24 text terminal
> and want to run emacs in it you want files to have no more than
> 79 characters per line. You can recreate this experience in an
> xterm or similar terminal by setting it to 80 characters and
> starting emacs with the -nw option.

If I understand correctly what you're describing, emacs -nw will display lines 
with up to 79 characters in a 80 column frame without wrapping. What, then, is 
the rationale for at most 78 characters?

-- Mark

Re: [jira] Created: (STDCXX-527) publish LOC metrics

[Mark Brown]

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Thu, 23 Aug 2007 09:21:33 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [jira] Created: (STDCXX-527) publish LOC metrics
> 
> Michael van der Westhuizen wrote:
>> Hi Martin,
>> 
>> On 8/23/07, Martin Sebor (JIRA) <[EMAIL PROTECTED]> wrote:
>> [snip]
>>> A recent project at work reminded me that it would be useful to keep
>>> track of LOC counts and other metrics for stdcxx on an ongoing basis
>>> and publish the data (perhaps in a graphical form) on the project web
>>> site. One tool that seems pretty popular for this purpose is David
>>> Wheeler's SLOCCount: http://www.dwheeler.com/sloccount/
>> 
>> Have you considered using http://www.ohloh.net/ for this?
> 
> Hi Michael,
> 
> No, I didn't know about Ohloh, thanks for the pointer! It looks
> very interesting. I think it might be worth a try. What do you
> all think, should I sign us up?

The metrics look interesting. At the risk of exposing those of us who haven't 
contributed much I say go for it!

-- Mark


GET FREE 5GB ONLINE STORAGE - Safely store your documents, photos and music 
online!
Visit http://www.inbox.com/storage to find out more!

RE: Exec utility test group reporting

[Mark Brown]

Hi Andrew,

I found myself needing documentation for the test driver in the past. Since  
you mentioned Doxygen comments in the exec utility, I'm wondering if there is 
generated documentation available somewhere that I don't know about. Could you 
point me in the right direction?

Many thanks!
-- Mark


> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Thu, 23 Aug 2007 11:48:26 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: Exec utility test group reporting
> 
> Greetings all.
> 
> Attached is a patch that aims to add some logic to the exec utility to
> report the type of executable being processed.  Part of the purpose of
> this change is to assist in making the result parsing more robust.
> 
> I am not particularly satisfied with this change for a couple reasons.
> One is because the doxygen comments are getting out of date, and need to
> be gone over.  The second is the way data is passed from cmdopt.cpp to
> display.cpp.  The current method used is to overload the target_opts
> struct to include the new parameter, but this feels like the wrong way
> to do things.  This method was chosen because the verbose flag is
> currently included there, but the exec subsystem shouldn't care about
> either of these things.  (The verbose output mode also feels like it was
> hacked on, but that's irrelevant to this topic.)
> 
> Does anyone have thoughts on this patch?  I should note that some
> changes to the windows infrastructure will be needed to keep the
> behavior in sync with the unix infrastructure.
> 
> --Andrew Black


KEEP SPYWARE OFF YOUR COMPUTER - Protect your computer with Spyware Terminator!
Visit http://www.spywareterminator.com/install and find out more!

Re: svn commit: r569152 - /incubator/stdcxx/branches/4.2.0/etc/config/src/LIMITS.cpp

[Mark Brown]

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Fri, 24 Aug 2007 09:29:36 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: svn commit: r569152 -
> /incubator/stdcxx/branches/4.2.0/etc/config/src/LIMITS.cpp
> 
> Andrew, please be sure to observe the 78 characters/line limit
> in Change Log entries as documented in bullet (3) of the Patch
> Format section on the Bugs page:
>http://incubator.apache.org/stdcxx/bugs.html#patch_format
> 
> The reason for this limit in both ChangeLogs and source files
> is that they all need to be readable on traditional VT100 text
> terminals.

I have seen coding styles with a 79 character limit (for instance Python) but I 
am curious what the rationale for the 78 character limit is when even the VT100 
displays have 80 columns?

-- Mark

Re: help scheduling issues

[Mark Brown]

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Fri, 24 Aug 2007 10:38:26 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: help scheduling issues
> 
> Greetings all.
> 
> I've taken a little time to glance over the open tasks which I reported
> but have not been assigned.  My analysis of these issues is as follows:
> 
> 336 (allow multiple config.h files in the same installation directory)
>   Marked as critical for the 4.2.0 release, and not anywhere on our radar
> as far as I can tell.

This seems like a useful feature. I commnonly work with multiple builds of 
stdcxx at the same time. Having them all share the same directory would save 
space and simplify my makefiles.

-- Mark


FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth

RE: expectation vs requirements for locale facets

[Mark Brown]

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Mon, 20 Aug 2007 05:20:32 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: RE: expectation vs requirements for locale facets
> 
> 
> 
> >Mark Brown wrote:
>> 
> >In my experience, the time_get facet isn't always able to
> >reliably parse international times and cannot parse every time
> >string produced by the time_put facet.
> 
> Yes, I see two different problems here. You can generate output with
> time_put<>::put for which there is no matching time_get<> method for
> parsing that data. What I mean is that you can easily format "%S %p" onto
> the stream, but there is no method in the time_get<> facet for reading
> that formatted data back. The stdcxx implemention provides an extension
> that allows you to do this, but it's an extension.
> 
> The other problem is the one that I'm more concerned about.
> 
> >I don't remember ever
> >having problems with spaces though.
> 
> Yeah, that is the problem. It is my interpretation that this is a
> requirement, but I'm not sure that anyone agrees with me on this. I don't
> really see the point in defining a system for input/output of times and
> dates if you can't read in the values that you write out.

Yeah, that wouldn't be a terribly useful system...

> 
> >On Linux at least, stdcxx
> >has no problems skipping leading space in time strings.
> 
> That is inconsistent with what I'm seeing. [see partial failure lists
> below]

You're right! I was sure I had used stdcxx to parse time strings with spaces in 
them but now that I've tried it I must acknowledge it really doesn't work. My 
sincere apologies for confusing the discussion!

-- Mark

RE: expectation vs requirements for locale facets

[Mark Brown]

Hi Travis,

In my experience, the time_get facet isn't always able to reliably parse 
international times and cannot parse every time string produced by the time_put 
facet. I don't remember ever having problems with spaces though. On Linux at 
least, stdcxx has no problems skipping leading space in time strings. Which 
locale and what operating system does it not do so for you?

-- Mark


> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Sun, 19 Aug 2007 00:09:01 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: expectation vs requirements for locale facets
> 
> 
> So I've got myself stuck a little bit, and I'm hoping to get some
> direction. The 22.locale.time.get.mt test that I'm writing currently has
> some problems. In the test I generate date/time strings like this...
> 
> switch (data.type_) {
> case MyTimeData::get_time:
> *np.put (std::ostreambuf_iterator(&nsb),
>  nio, ' ', &data.time_, 'X') = '\0';
> break;
> 
> In the test threads, I attempt to read the data back like this...
> 
> switch (data.type_) {
> case MyTimeData::get_time:
> ng.get_time (std::istreambuf_iterator(&nsb),
>  std::istreambuf_iterator(), nio,
>  state, &local);
> RW_ASSERT (local.tm_hour == data.time_.tm_hour);
> RW_ASSERT (local.tm_min == data.time_.tm_min);
> RW_ASSERT (local.tm_sec == data.time_.tm_sec);
> break;
> 
> The problem is that some locales pad their date/time output with
> whitespace [like '7. 6. 1988' or ' 7.6.1988'] and I'm unable to use
> num_get<>::get_[time,date] to read what is written by num_put<>::put. It
> is my understanding that I should be able to do so. Is this a bug, a
> known issue, or is it acceptable behavior that I need to code around in
> the test?
> 
> Travis


FREE 3D EARTH SCREENSAVER - Watch the Earth right on your desktop!
Check it out at http://www.inbox.com/earth

[jira] Commented: (STDCXX-518) std::string copy constructor slow

[Mark Brown (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12519279
 ] 

Mark Brown commented on STDCXX-518:
---

I thought timings for multipled threads might be of interest. Unfortunately, I 
have only 2 CPUs to test on.

$ time ./string-copy.gcc 1

real0m9.739s
user0m19.257s
sys 0m0.060s
$ time ./string-copy.stlport 1

real0m20.906s
user0m40.211s
sys 0m0.056s
$ time LD_LIBRARY_PATH=../lib ./string-copy 1

real0m17.585s
user0m34.698s
sys 0m0.076s



#include 
#include 
#include 
#include 


std::string strings [256];
const std::size_t num_strings = sizeof strings / sizeof *strings;
unsigned long n;

extern "C" void* test_copy_ctor (void*)
{
for (unsigned long i = 0; i != n; ++i) {
const std::size_t index = i % num_strings;
const std::string copy (strings [index]);
assert (copy.length () == index);
}

return 0;
}

int main (int argc, char *argv[])
{
n = argc < 2 ? 0 : std::strtoul (argv [1], 0, 10);

for (unsigned long i = 0; i != num_strings; ++i)
strings [i].assign (i, 'x');

pthread_t thread [2];
const std::size_t num_threads = sizeof thread / sizeof *thread;

for (std::size_t i = 0; i < num_threads; ++i)
pthread_create (thread + i, 0, test_copy_ctor, 0);

for (std::size_t i = 0; i < num_threads; ++i)
pthread_join (thread [i], 0);
}


> std::string copy constructor slow
> -
>
> Key: STDCXX-518
> URL: https://issues.apache.org/jira/browse/STDCXX-518
> Project: C++ Standard Library
>  Issue Type: Improvement
>  Components: 21. Strings
>Affects Versions: 4.1.3
> Environment: gcc 4.1.2, x86_64
>Reporter: Mark Brown
>
> When thread safety is enabled in stdcxx the string copy constructor is more 
> than ten times slower than when it's not, and twice as slow as the same copy 
> constructor in gcc 4.1.2 on Linux (x86_64), but slightly faster than with 
> STLport 5.1.3. The timings were done on Intel x86_64 at 2.4GHz:
> BUILDMODE=shared,optimized:
> $ time LD_LIBRARY_PATH=../lib ./string-copy 1
> real0m0.482s
> user0m0.480s
> sys 0m0.000s
> BUILDMODE=shared,optimized,pthread:
> $ time LD_LIBRARY_PATH=../lib ./string-copy 1
> real0m10.157s
> user0m10.041s
> sys 0m0.032s
> gcc 4.1.2 with -O2 -m64:
> $ time ./string-copy.gcc 1
> real0m4.280s
> user0m4.260s
> sys 0m0.020s
> gcc 4.1.2 with STLport 5.1.3 (-D_REENTRANT -O2 -m64 -lpthread):
> $ time ./string-copy.stlport 1
> real0m12.479s
> user0m12.473s
> sys 0m0.004s
> #include 
> #include 
> #include 
> int main (int argc, char *argv[])
> {
> const unsigned long n = argc < 2 ? 0 : std::strtoul (argv [1], 0, 10);
> std::string strings [256];
> const std::size_t num_strings = sizeof strings / sizeof *strings;
> for (unsigned long i = 0; i != num_strings; ++i)
> strings [i].assign (i, 'x');
> for (unsigned long i = 0; i < n; ++i) {
> const std::size_t length = i % num_strings;
> const std::string str (strings [length]);
> assert (str.size () == length);
> }
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-518) std::string copy constructor slow

[Mark Brown (JIRA)]

std::string copy constructor slow
-

 Key: STDCXX-518
 URL: https://issues.apache.org/jira/browse/STDCXX-518
 Project: C++ Standard Library
  Issue Type: Improvement
  Components: 21. Strings
Affects Versions: 4.1.3
 Environment: gcc 4.1.2, x86_64
Reporter: Mark Brown


When thread safety is enabled in stdcxx the string copy constructor is more 
than ten times slower than when it's not, and twice as slow as the same copy 
constructor in gcc 4.1.2 on Linux (x86_64), but slightly faster than with 
STLport 5.1.3. The timings were done on Intel x86_64 at 2.4GHz:

BUILDMODE=shared,optimized:
$ time LD_LIBRARY_PATH=../lib ./string-copy 1

real0m0.482s
user0m0.480s
sys 0m0.000s

BUILDMODE=shared,optimized,pthread:
$ time LD_LIBRARY_PATH=../lib ./string-copy 1

real0m10.157s
user0m10.041s
sys 0m0.032s

gcc 4.1.2 with -O2 -m64:
$ time ./string-copy.gcc 1

real0m4.280s
user0m4.260s
sys 0m0.020s

gcc 4.1.2 with STLport 5.1.3 (-D_REENTRANT -O2 -m64 -lpthread):
$ time ./string-copy.stlport 1

real0m12.479s
user0m12.473s
sys 0m0.004s


#include 
#include 
#include 


int main (int argc, char *argv[])
{
const unsigned long n = argc < 2 ? 0 : std::strtoul (argv [1], 0, 10);

std::string strings [256];

const std::size_t num_strings = sizeof strings / sizeof *strings;
for (unsigned long i = 0; i != num_strings; ++i)
strings [i].assign (i, 'x');

for (unsigned long i = 0; i < n; ++i) {
const std::size_t length = i % num_strings;
const std::string str (strings [length]);
assert (str.size () == length);
}
}


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [PATCH] for STDCXX-491 - string::push_back() slow

[Mark Brown]

Neat graph! What software did you use to create it?

I'm also curious about the precipitous drop in the performance of both stdcxx 
and stlport around 32 elements. Do you have an explanation for it?

-- Mark


> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Sun, 05 Aug 2007 21:28:30 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [PATCH] for STDCXX-491 - string::push_back() slow
> 
> Looks like ezmlm stripped the grap attached to my previous post so
> I attached it to the issue instead:
> 
> http://issues.apache.org/jira/secure/attachment/12363211/push_back.png
> 
> Martin
> 
> Martin Sebor wrote:
>> FWIW, I've benchmarked the latest push_back() against stdcxx 4.1.3
>> and a number of other implementations, including STLport 5.1.3. We
>> are faster than any other implementation except STLport, and close
>> to STLport in the general case. STLport has an advantage for short
>> strings (less than 16 characters), most likely because of the short
>> string optimization.
>> 
>> Martin
>> 
>> Martin Sebor wrote:
>>> Farid Zaripov wrote:
> -Original Message-
> From: Martin Sebor [mailto:[EMAIL PROTECTED] On Behalf Of Martin
> Sebor
> Sent: Tuesday, July 24, 2007 7:40 AM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [PATCH] for STDCXX-491 - string::push_back() slow
> 
> mark.g.brown wrote:
>> Hi all,
>> 
>> The attached simple patch speeds up push_back() nearly six times
>> relative to stdcxx 4.1.3 and makes it more than twice faster that
>> gcc's.
> Let me test your patch for regressions and if it passes I'll commit
> it tomorrow.
 
   I see the difference between the old push_back() behavior and after
 this patch.
 The append (size_type (1), __c); also appends terminating NULL
 character
 (string.cc, line 472). Below is the corrections to the patch:
>>> 
>>> Ah, yes, good catch!
>>> 
>>> On the subject of the terminating NUL, I wonder it would simplify
>>> (and speed up) the implementation if we appended the terminating
>>> NUL in c_str() instead in every modifying member function. We'd
>>> still need to allocate enough memory for it because c_str() isn't
>>> allowed to invalidate iterators, pointers, and references into
>>> the object but we might be able to save ourselves a few CPU
>>> cycles if we set data()[size()] to charT() only in c_str().
>>> 
>>> Hmmm, something to think about...
>>> 
>>> Martin
>>> 
 
>>  template   inline
>> void basic_string<_CharT, _Traits, _Allocator>::
>> +push_back (value_type __c)
>> +{
>> +const size_type __size = size () + 1;
>> +
>> +if (   capacity () < __size
>> +|| size_type (1) < size_type (_C_pref ()->_C_get_ref ()))
>> +append (1, __c);
>> +else {
>> +traits_type::assign (_C_data [size ()], __c);
 // append the terminating NUL character
 traits_type::assign (_C_data [__size], value_type ());
>> +_C_pref ()->_C_size._C_size = __size;
>> +}
>> +}
 
 Farid.
>>> 
>>> 
>> 

RE: Taking tasks for STDCXX-391

[Mark Brown]

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Mon, 30 Jul 2007 17:37:00 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: Taking tasks for STDCXX-391
> 
> Hi, I am new to this list. I am a colleague of Martin Sebor, and I am
> going to start working on some of the tasks in his JIRA 391. I will be
> creating subtasks for the items listed in this JIRA and addressing them.
> If someone could tell me how to go about assigning myself to a new
> subtask I would appreciate it. I created one for adding copyright
> notices, but could not figure out how to assign it to myself.

Hi Marc,

From the Jira manual it sounds like you need to have the Assign Issues 
permission in order to assign issues, and that the Jira administrator decides 
who gets to have that permission. I also don't have this permission but so far 
I haven't had the need for it so I'm afraid I can't offer any suggestion for 
how to go about obtaining it.

http://www.atlassian.com/software/jira/docs/latest/permissions.html#permission_schemes

-- Mark

> 
> Regards,
> 
> Marc Betz

[jira] Created: (STDCXX-493) std::string::append() slow

[Mark Brown (JIRA)]

std::string::append() slow
--

 Key: STDCXX-493
 URL: https://issues.apache.org/jira/browse/STDCXX-493
 Project: C++ Standard Library
  Issue Type: Bug
  Components: 21. Strings
Affects Versions: 4.1.3
 Environment: gcc 4.1.2 on Linux/x86_64
Reporter: Mark Brown


This is a similar problem to STDCXX-492: all overloads of string::append() are 
slower than the same overloads in gcc:

$ let n=0; while [ $n -lt 3 ]; do time LD_LIBRARY_PATH=../lib 
./append-stdcxx-4.1.3 5 $n; let n=`expr $n + 1`; done

real0m11.221s
user0m9.941s
sys 0m1.104s

real0m13.065s
user0m11.661s
sys 0m1.236s

real0m7.837s
user0m6.660s
sys 0m1.160s

$ let n=0; while [ $n -lt 3 ]; do time ./append-gcc-4.1.2 5 $n; let 
n=`expr $n + 1`; done

real0m4.865s
user0m4.172s
sys 0m0.692s

real0m7.617s
user0m6.920s
sys 0m0.696s

real0m5.787s
user0m5.068s
sys 0m0.720s

The program I used to do the comaprison is below:

#include 
#include 
#include 

int main (int argc, char *argv[])
{
const int N = argc < 2 ? 1 : std::atoi (argv [1]);
const int op = argc < 3 ? 0 : std::atoi (argv [2]);

std::string str;

const std::string x ("X");

if (op == 0) {
for (int i = 0; i < N; ++i)
str.append (1, 'x');
} else if (op == 1) {
for (int i = 0; i < N; ++i)
str.append ("x");
} else {
for (int i = 0; i < N; ++i)
str.append (x);
}

assert (str.size () == std::size_t (N));
}


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-492) std::string::operator+=() slow

[Mark Brown (JIRA)]

std::string::operator+=() slow
--

 Key: STDCXX-492
 URL: https://issues.apache.org/jira/browse/STDCXX-492
 Project: C++ Standard Library
  Issue Type: Bug
  Components: 21. Strings
Affects Versions: 4.1.3
 Environment: gcc 4.1.2 on Linux/x86_64
Reporter: Mark Brown


Comparing overloads of string::operator+=() in stdcxx with the same functions 
in gcc 4.1.2, stdcxx is up to twice slower than gcc:

$ time ./op_plus_equal-stdcxx 1 0

real0m2.241s
user0m1.932s
sys 0m0.204s
$ time ./op_plus_equal-stdcxx 1 1

real0m2.540s
user0m2.344s
sys 0m0.196s
$ time ./op_plus_equal-stdcxx 1 2

real0m1.492s
user0m1.308s
sys 0m0.184s
$ time ./op_plus_equal-gcc 1 0

real0m0.883s
user0m0.728s
sys 0m0.156s
$ time ./op_plus_equal-gcc 1 1

real0m1.589s
user0m1.424s
sys 0m0.168s
$ time ./op_plus_equal-gcc 1 2

real0m1.131s
user0m0.976s
sys 0m0.156s


#include 
#include 
#include 

int main (int argc, char *argv[])
{
const int N = argc < 2 ? 1 : std::atoi (argv [1]);
const int op = argc < 3 ? 0 : std::atoi (argv [2]);

std::string str;

const std::string x ("x");

if (op == 0) {
for (int i = 0; i < N; ++i)
str += 'x';
} else if (op == 1) {
for (int i = 0; i < N; ++i)
str += "x";
} else {
for (int i = 0; i < N; ++i)
str += x;
}

assert (str.size () == std::size_t (N));
}


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-491) string::push_back() slow

[Mark Brown (JIRA)]

string::push_back() slow


 Key: STDCXX-491
 URL: https://issues.apache.org/jira/browse/STDCXX-491
 Project: C++ Standard Library
  Issue Type: Bug
  Components: 21. Strings
Affects Versions: 4.1.3
 Environment: gcc 4.1.2, Linux/x86_64
Reporter: Mark Brown


According to my timings string::push_back() in stdcxx 4.1.3 is more than twice 
as slow than the same function in gcc 4.1.2 on Linux x86_64:

$ time ./push_back-stdcxx 1

real0m2.175s
user0m2.004s
sys 0m0.172s

$ time ./push_back-gcc 1

real0m0.924s
user0m0.760s
sys 0m0.164s


#include 
#include 
#include 

int main (int argc, char *argv[])
{
const int N = argc < 2 ? 1 : std::atoi (argv [1]);

std::string str;

for (int i = 0; i < N; ++i)
str.push_back ('x');

assert (str.size () == std::size_t (N));
}

Comparing the generated assembly, the gcc push_back() is mostly inline but the 
stdcxx push_back() is not:

stdcxx:
_Z8pushbackRSsc:
.LFB449:
movq(%rdi), %rax
movl%esi, %edx
movl$1, %ecx
movsbl  %dl,%r8d
xorl%edx, %edx
movq-8(%rax), %rsi
jmp _ZNSs7replaceEmmmc


gcc:
_Z8pushbackRSsc:
.LFB904:
movq%rbp, -16(%rsp)
.LCFI0:
movq%r12, -8(%rsp)
.LCFI1:
movq%rdi, %rbp
movq%rbx, -24(%rsp)
.LCFI2:
subq$24, %rsp
.LCFI3:
movq(%rdi), %rax
movl%esi, %r12d
subq$24, %rax
movq(%rax), %rbx
addq$1, %rbx
cmpq8(%rax), %rbx
ja  .L2
movl16(%rax), %eax
testl   %eax, %eax
jg  .L2
.L4:
movq(%rbp), %rdx
movq-24(%rdx), %rax
movb%r12b, (%rdx,%rax)
movq(%rbp), %rax
subq$24, %rax
movl$0, 16(%rax)
movq%rbx, (%rax)
movb$0, 24(%rax,%rbx)
movq(%rsp), %rbx
movq8(%rsp), %rbp
movq16(%rsp), %r12
addq$24, %rsp
ret
.p2align 4,,7
.L2:
movq%rbx, %rsi
movq%rbp, %rdi
call_ZNSs7reserveEm
jmp .L4

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (STDCXX-489) [Intel C++ 10.0/Linux] BUILDMODE=narrow has no effect

[Mark Brown (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513707
 ] 

Mark Brown commented on STDCXX-489:
---

Hi Andrew,

Can you suggest where to get the correct iccvars.sh script or how to change it? 
I only have one iccvars.sh in /opt/intel/cce/10.0.025/bin and I don't see any 
options that control which type of code the compiler generates. Is it possible 
that the compiler doesn't support 32-bit code on x86_64 and that I need to 
install another one?

Thanks!
--Mark

> [Intel C++ 10.0/Linux] BUILDMODE=narrow has no effect
> -
>
> Key: STDCXX-489
> URL: https://issues.apache.org/jira/browse/STDCXX-489
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 4.2
> Environment: Intel C++ 10 on Linux
>Reporter: Mark Brown
>
> Configuring stdcxx for 32-bits using 
> BUILDMODE=pthreads,archive,optimized,narrow on x86_64 I see the system 
> architecture is "LP64 little endian" instead of "ILP32 little endian." It 
> looks like the "narrow" in BUILDMODE has no effect, kind of like "wide" had 
> no effect in bug STDCXX-470.
> $ nice make BUILDDIR=/home/mbrown/stdcxx-icc-10.0-12s 
> BUILDMODE=pthreads,archive,optimized,narrow CONFIG=icc.config
> creating BUILDDIR=/home/mbrown/stdcxx-icc-10.0-12s
> generating /home/mbrown/stdcxx-icc-10.0-12s/makefile.in from 
> /home/mbrown/stdcxx/etc/config/icc.config
> make[1]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s'
> make[2]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s/include'
> make config
> make[3]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s/include'
> configuring stdcxx 4.2.0 for icc-10.0 on linux-2.6.18-1.2798.fc6-x86_64
> checking if the compiler is sane   ok (invoked with icc)
> checking if the linker is sane ok (invoked with icc)
> checking system architecture   LP64 little endian

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-489) [Intel C++ 10.0/Linux] BUILDMODE=narrow has no effect

[Mark Brown (JIRA)]

[Intel C++ 10.0/Linux] BUILDMODE=narrow has no effect
-

 Key: STDCXX-489
 URL: https://issues.apache.org/jira/browse/STDCXX-489
 Project: C++ Standard Library
  Issue Type: Bug
  Components: Configuration
Affects Versions: 4.2
 Environment: Intel C++ 10 on Linux
Reporter: Mark Brown


Configuring stdcxx for 32-bits using 
BUILDMODE=pthreads,archive,optimized,narrow on x86_64 I see the system 
architecture is "LP64 little endian" instead of "ILP32 little endian." It looks 
like the "narrow" in BUILDMODE has no effect, kind of like "wide" had no effect 
in bug STDCXX-470.

$ nice make BUILDDIR=/home/mbrown/stdcxx-icc-10.0-12s 
BUILDMODE=pthreads,archive,optimized,narrow CONFIG=icc.config
creating BUILDDIR=/home/mbrown/stdcxx-icc-10.0-12s
generating /home/mbrown/stdcxx-icc-10.0-12s/makefile.in from 
/home/mbrown/stdcxx/etc/config/icc.config
make[1]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s'
make[2]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s/include'
make config
make[3]: Entering directory `/home/mbrown/stdcxx-icc-10.0-12s/include'

configuring stdcxx 4.2.0 for icc-10.0 on linux-2.6.18-1.2798.fc6-x86_64

checking if the compiler is sane   ok (invoked with icc)
checking if the linker is sane ok (invoked with icc)
checking system architecture   LP64 little endian


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

RE: [VOTE] ready to graduate

[Mark Brown]

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Thu, 05 Jul 2007 15:14:29 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: [VOTE] ready to graduate
> 
> Our mentors as well as a number of IPMC members recently expressed
> confidence in stdcxx being ready to graduate out of the incubator
> (see the thread starting with msg14476 below).
> 
> In order to propose graduation to the Incubator PMC we all need to
> formally agree that we are ready. This is a vote to ascertain this
> agreement.
> 
> [ ] Check here (or use +1) to indicate you agree that stdcxx is
>  ready to graduate.

I'm not a member of the team so my vote probably doesn't count for much but 
from what I've seen the project has been ready for some time. So here's my +1 
for whatever it's worth. Good luck!

-- Mark


KEEP SPYWARE OFF YOUR COMPUTER - Protect your computer with Spyware Terminator!
Visit http://www.spywareterminator.com/install and find out more!

RE: status of thread safety tests

[Mark Brown]

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Tue, 26 Jun 2007 18:57:44 +0300
> To: stdcxx-dev@incubator.apache.org
> Subject: RE: status of thread safety tests
> 
>> -Original Message-
>> From: Mark Brown [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, June 26, 2007 5:06 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: RE: status of thread safety tests
>> 
>> 22.locale.num.put.mt gets a SIGSEGV on my system (Fedora 6)
>> even with a single thread. Here's the output of gdb:
> 
>   The same trouble on MSVC. And I found the problem.
> 
> struct Ios: std::ios {
> } io;
> 
>   Here should be defined ctor invoking ios_base::init() according to
> 27.4.2.7 p1: Ios () { this->init (0); }
> 
>   The same bug present in 22.locale.money.put.mt and
> 22.locale.time.put.mt tests.
> 
>   Fixed thus: http://svn.apache.org/viewvc?view=rev&rev=550833

Hi Farid,

This change appears to have cleared up the original issue. However, with 
multiple threads the test now sometimes crashes with the following error:

terminate called after throwing an instance of 'std::runtime_error'
  what():  /home/mbrown/stdcxx/src/setlocale.cpp:130: 
__rw::__rw_setlocale::__rw_setlocale(const char*, int, int): bad locale name: 
"PY"

The name of the locale varies and is sometimes garbage so it might be caused by 
some memory corruption.

-- Mark

> 
>   I'm not sure if this patch resolves the STDCXX-450 issue.
> 
> Farid.


GET FREE 5GB ONLINE STORAGE - Safely store your documents, photos and music 
online!
Visit http://www.inbox.com/storage to find out more!

RE: list of available cross-build result views

[Mark Brown]

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Sat, 16 Jun 2007 15:59:11 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: list of available cross-build result views
> 
> ...is on the page below. This page and the cross-build views are
> all set up to get generated from the all-platform build result
> data at 8AM PDT every day.
> 
>http://people.apache.org/~sebor/stdcxx/results/builds.html

Martin,

This looks interesting. I have a question though. There are a number of black 
cells in the test tables on most of the pages. For instance, the 
22.locale.num.put.mt test on the redhat_as-5.0-em64t-gcc-4.1.1.html page. Does 
it mean the test did not run? I looked for the test on the 
redhat_as-5.0-em64t-gcc-64b-4.1.1-12d-log.gz.txt page referenced from column 12 
(the closest I could find to 15D). The status of the test is SEGV but when I 
looked in the log I couldn't find the test there.

-- Mark

crash in 22.locale.num.put.mt (was RE: status of thread safety tests)

[Mark Brown]

It might be more helpful if I include the debugging information. The test runs 
okay with just one thread in a debug build so this output is for two threads.

(gdb) r --nthreads=2
Starting program: /home/mbrown/stdcxx-gcc-4.1.1-15D/tests/22.locale.num.put.mt 
--nthreads=2
[Thread debugging using libthread_db enabled]
[New Thread 46912499588704 (LWP 23444)]
# INFO (S1) (10 lines):
# TEXT: 
# COMPILER: gcc 4.1.1, __VERSION__ = "4.1.1 20070105 (Red Hat 4.1.1-51)"
# ENVIRONMENT: amd64/LP64 running linux-elf (unknown release) with glibc 2.5
# FILE: 22.locale.num.put.mt.cpp
# COMPILED: Jun 26 2007, 08:08:46
# COMMENT: thread safety


# CLAUSE: lib.locale.num.put

# NOTE (S2) (5 lines):
# TEXT: executing "locale -a > /tmp/tmpfile-6SA0KQ"
# CLAUSE: lib.locale.num.put
# FILE: process.cpp
# LINE: 274

# INFO (S1) (3 lines):
# TEXT: testing std::num_put with 2 threads, 20 iterations each, in 
locales { "aa_DJ" "aa_DJ.iso88591" "aa_DJ.utf8" "aa_ER" "[EMAIL PROTECTED]" 
"aa_ER.utf8" "[EMAIL PROTECTED]" "aa_ET" "aa_ET.utf8" "af_ZA" "af_ZA.iso88591" 
"af_ZA.utf8" "am_ET" "am_ET.utf8" "an_ES" "an_ES.iso885915" "an_ES.utf8" 
"ar_AE" "ar_AE.iso88596" "ar_AE.utf8" "ar_BH" "ar_BH.iso88596" "ar_BH.utf8" 
"ar_DZ" "ar_DZ.iso88596" "ar_DZ.utf8" "ar_EG" "ar_EG.iso88596" "ar_EG.utf8" 
"ar_IN" "ar_IN.utf8" "ar_IQ" }
# CLAUSE: lib.locale.num.put

# INFO (S1) (3 lines):
# TEXT: exercising std::num_put
# CLAUSE: lib.locale.num.put

[New Thread 1084229952 (LWP 23447)]
[New Thread 1094719808 (LWP 23448)]
*** glibc detected *** 
/home/mbrown/stdcxx-gcc-4.1.1-15D/tests/22.locale.num.put.mt: double free or 
corruption (fasttop): 0x00649720 ***
=== Backtrace: =
/lib64/libc.so.6[0x39f826ea30]
/lib64/libc.so.6(cfree+0x8c)[0x39f827214c]
/home/mbrown/stdcxx-gcc-4.1.1-15D/lib/libstd15D.so(_ZN4__rw15__rw_deallocateEPvmi+0x1c)[0x2ab18a9e]
/home/mbrown/stdcxx-gcc-4.1.1-15D/lib/libstd15D.so(_ZNSaIcE10deallocateEPcm+0x26)[0x2ab29626]
/home/mbrown/stdcxx-gcc-4.1.1-15D/lib/libstd15D.so(_ZNSs9_C_unlinkEPc+0xb6)[0x2ab296de]
/home/mbrown/stdcxx-gcc-4.1.1-15D/lib/libstd15D.so(_ZNSsD1Ev+0x1a)[0x2ab2ec86]
/home/mbrown/stdcxx-gcc-4.1.1-15D/lib/libstd15D.so(_ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6_C_putES3_RSt8ios_baseciPKv+0x6b2)[0x2ab35448]
/home/mbrown/stdcxx-gcc-4.1.1-15D/lib/libstd15D.so(_ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE6do_putES3_RSt8ios_basecl+0x3d)[0x2ab3564b]
/home/mbrown/stdcxx-gcc-4.1.1-15D/lib/libstd15D.so(_ZNKSt7num_putIcSt19ostreambuf_iteratorIcSt11char_traitsIcEEE3putES3_RSt8ios_basecl+0x43)[0x2ab26c07]
/home/mbrown/stdcxx-gcc-4.1.1-15D/tests/22.locale.num.put.mt[0x405091]
/lib64/libpthread.so.0[0x39fae06305]
/lib64/libc.so.6(clone+0x6d)[0x39f82cd50d]
=== Memory map: 
0040-0042c000 r-xp  08:02 22086788   
/home/mbrown/stdcxx-gcc-4.1.1-15D/tests/22.locale.num.put.mt
0062c000-0062e000 rw-p 0002c000 08:02 22086788   
/home/mbrown/stdcxx-gcc-4.1.1-15D/tests/22.locale.num.put.mt
0062e000-00651000 rw-p 0062e000 00:00 0  [heap]
4000-40001000 ---p 4000 00:00 0 
40001000-40a01000 rwxp 40001000 00:00 0 
40a01000-40a02000 ---p 40a01000 00:00 0 
40a02000-41402000 rwxp 40a02000 00:00 0 
39f700-39f701a000 r-xp  08:02 17006594   
/lib64/ld-2.5.so
39f7219000-39f721a000 r--p 00019000 08:02 17006594   
/lib64/ld-2.5.so
39f721a000-39f721b000 rw-p 0001a000 08:02 17006594   
/lib64/ld-2.5.so
39f820-39f8344000 r-xp  08:02 17006597   
/lib64/libc-2.5.so
39f8344000-39f8544000 ---p 00144000 08:02 17006597   
/lib64/libc-2.5.so
39f8544000-39f8548000 r--p 00144000 08:02 17006597   
/lib64/libc-2.5.so
39f8548000-39f8549000 rw-p 00148000 08:02 17006597   
/lib64/libc-2.5.so
39f8549000-39f854e000 rw-p 39f8549000 00:00 0 
39f860-39f8682000 r-xp  08:02 17006804   
/lib64/libm-2.5.so
39f8682000-39f8881000 ---p 00082000 08:02 17006804   
/lib64/libm-2.5.so
39f8881000-39f8882000 r--p 00081000 08:02 17006804   
/lib64/libm-2.5.so
39f8882000-39f8883000 rw-p 00082000 08:02 17006804   
/lib64/libm-2.5.so
39fae0-39fae15000 r-xp  08:02 17006792   
/lib64/libpthread-2.5.so
39fae15000-39fb014000 ---p 00015000 08:02 17006792   
/lib64/libpthread-2.5.so
39fb014000-39fb015000 r--p 00014000 08:02 17006792   
/lib64/libpthread-2.5.so
39fb015000-39fb016000 rw-p 00015000 08:02 17006792   
/lib64/libpthread-2.5.so
39fb016000-39fb01a000 rw-p 39fb016000 00:00 0 
3a0500-3a0500d000 r-xp  08:02 17006751   
/lib64/libgcc_s-4.1.1-20070105.so.1
3a0500d000-3a0520c

RE: status of thread safety tests

[Mark Brown]

22.locale.num.put.mt gets a SIGSEGV on my system (Fedora 6) even with a single 
thread. Here's the output of gdb:

$ gdb ./22.locale.num.put.mt
GNU gdb Red Hat Linux (6.5-15.fc6rh)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...
(no debugging symbols found)
Using host libthread_db library "/lib64/libthread_db.so.1".

(gdb) run --nthreads=1
Starting program: /home/mbrown/stdcxx-gcc-4.1.1-12D/tests/22.locale.num.put.mt -
-nthreads=1
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 46912499232352 (LWP 32189)]
(no debugging symbols found)
# INFO (S1) (10 lines):
# TEXT: 
# COMPILER: gcc 4.1.1, __VERSION__ = "4.1.1 20070105 (Red Hat 4.1.1-51)"
# ENVIRONMENT: amd64/LP64 running linux-elf (unknown release) with glibc 2.5
# FILE: 22.locale.num.put.mt.cpp
# COMPILED: Jun 26 2007, 07:52:50
# COMMENT: thread safety


# CLAUSE: lib.locale.num.put

# NOTE (S2) (5 lines):
# TEXT: executing "locale -a > /tmp/tmpfile-st2gNr"
# CLAUSE: lib.locale.num.put
# FILE: process.cpp
# LINE: 274

# INFO (S1) (3 lines):
# TEXT: testing std::num_put with 1 thread, 20 iterations each, in lo
cales { "aa_DJ" "aa_DJ.iso88591" "aa_DJ.utf8" "aa_ER" "[EMAIL PROTECTED]" 
"aa_ER.utf8"
 "[EMAIL PROTECTED]" "aa_ET" "aa_ET.utf8" "af_ZA" "af_ZA.iso88591" "af_ZA.utf8" 
"
am_ET" "am_ET.utf8" "an_ES" "an_ES.iso885915" "an_ES.utf8" "ar_AE" "ar_AE.iso885
96" "ar_AE.utf8" "ar_BH" "ar_BH.iso88596" "ar_BH.utf8" "ar_DZ" "ar_DZ.iso88596" 
"ar_DZ.utf8" "ar_EG" "ar_EG.iso88596" "ar_EG.utf8" "ar_IN" "ar_IN.utf8" "ar_IQ" 
}
# CLAUSE: lib.locale.num.put

# INFO (S1) (3 lines):
# TEXT: exercising std::num_put
# CLAUSE: lib.locale.num.put

[New Thread 1084229952 (LWP 32194)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1084229952 (LWP 32194)]
0x2aafb027 in std::locale::locale ()
   from /home/mbrown/stdcxx-gcc-4.1.1-12D/lib/libstd12D.so
(gdb) where
#0  0x2aafb027 in std::locale::locale ()
   from /home/mbrown/stdcxx-gcc-4.1.1-12D/lib/libstd12D.so
#1  0x00403eea in thread_func ()
#2  0x0039fae06305 in start_thread () from /lib64/libpthread.so.0
#3  0x0039f82cd50d in clone () from /lib64/libc.so.6
#4  0x in ?? ()


-- Mark


> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Mon, 18 Jun 2007 21:20:27 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: status of thread safety tests
> 
> I've been working on a document listing the thread safety tests
> in stdcxx/trunk and their current status:
> 
>http://people.apache.org/~sebor/thread_safety_tests.html
> 
> The goal is to have a full understanding of all the problems
> and address them (or at least the most important ones) in the
> final 4.2.0 release.
> 
> The document is still a work in progress, as is the test suite.
> Not all tests have been migrated from the Rogue Wave test suite
> in Perforce over to ASF Subversion. For those tests the links
> that point to the Perforce source repository won't work.

[jira] Created: (STDCXX-436) [Linux] MB_LEN_MAX incorrect

[Mark Brown (JIRA)]

[Linux] MB_LEN_MAX incorrect


 Key: STDCXX-436
 URL: https://issues.apache.org/jira/browse/STDCXX-436
 Project: C++ Standard Library
  Issue Type: Bug
  Components: 18. Language Support
Affects Versions: 4.2
 Environment: gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)
Reporter: Mark Brown


On my Linux system MB_LEN_MAX is normally defined to 16 but when I use the 
macro in a program compiled with stdcxx the macro evaluates to 1. The test case 
goes like this:

$ cat test.cpp && make CPPOPTS="-DGETCONF_MB_LEN_MAX=`getconf MB_LEN_MAX`" test 
&& ./test
#include 
#include 

int main ()
{
assert (MB_LEN_MAX == GETCONF_MB_LEN_MAX);
}
gcc -c -I/home/mbrown/stdcxx/include/ansi -D_RWSTDDEBUG
-I/home/mbrown/stdcxx/include -I/home/mbrown/stdcxx-gcc-4.1.1-11s/include 
-I/home/mbrown/stdcxx/examples/include -DGETCONF_MB_LEN_MAX=16 -pedantic 
-nostdinc++ -g  -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings 
-Wno-long-long -Wcast-align   test.cpp
gcc u.o -o u  -L/home/mbrown/stdcxx-gcc-4.1.1-11s/lib  -lstd11s -lsupc++ -lm 
test: test.cpp:6: int main(): Assertion `1 == 16' failed.
Aborted


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-435) [Linux] std::codecvt_byname("*.UTF-8").in() to_next greater than expected

[Mark Brown (JIRA)]

[Linux] std::codecvt_byname("*.UTF-8").in() to_next greater than expected
-

 Key: STDCXX-435
 URL: https://issues.apache.org/jira/browse/STDCXX-435
 Project: C++ Standard Library
  Issue Type: Bug
  Components: 22. Localization
Affects Versions: 4.1.3
 Environment: gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)
Reporter: Mark Brown


When compiled with gcc 4.1.1 on Linux the program below runs successfully to 
completion as it should. When compiled with stdcxx the facet returns  a to_next 
value that is greater than the number of internal (wchar_t) characters actually 
produced by the conversion and consequently the program aborts.

$ cat t.cpp && make t && ./t
#include 
#include 
#include 

int main ()
{
const std::locale utf8 ("en_US.UTF-8");
typedef std::codecvt UTF8_Cvt;

const UTF8_Cvt &cvt = std::use_facet(utf8);

const char src[] = "abc";
wchar_t dst [2] = { L'\0' };

const char* from_next;

wchar_t* to_next;

std::mbstate_t state = std::mbstate_t ();

const std::codecvt_base::result res =
cvt.in (state,
src, src + 1, from_next,
dst, dst + 2, to_next);

assert (1 == from_next - src);
assert (1 == to_next - dst);
assert ('a' == dst [0]);
}

gcc -c -I/home/mbrown/stdcxx/include/ansi -D_RWSTDDEBUG
-I/home/mbrown/stdcxx/include -I/build/mbrown/stdcxx-gcc-4.1.1-11S/include 
-I/home/mbrown/stdcxx/examples/include  -pedantic -nostdinc++ -g   -W -Wall 
-Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align   
t.cpp
t.cpp: In function 'int main()':
t.cpp:21: warning: unused variable 'res'
gcc t.o -o t  -L/build/mbrown/stdcxx-gcc-4.1.1-11S/lib  -lstd11S -lsupc++ -lm 
t: t.cpp:26: int main(): Assertion `1 == from_next - src' failed.
Aborted


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

old iostream benchmark

[Mark Brown]

I came across a post from 2002 with a comparison between C stdio, Classic 
Iostreams, and Standard Iostreams. I thought it might be interesting to post it 
here for reference and re-run the numbers today with the latest versions of 
compilers and libraries: http://gcc.gnu.org/ml/libstdc++/2002-12/msg00347.html

-- Mark

Re: infinite loop in exec

[Mark Brown]

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Wed, 23 May 2007 15:55:04 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: infinite loop in exec
> 
> Andrew Black wrote:
>> Probably wouldn't hurt to open a jira for this, as I'm currently running
>> a sweep of results for our other products, and this may take a little
>> time to look into.
> 
> Wow, looks like it's already done! (Thanks Mark!)

Sorry about that! I'm afraid I got a little overzealous there.

I have offered to help Martin with the triage of issues and in my haste to do 
something useful I may have jumped the gun on this one. I will try to exercise 
more restraint in the future.

-- Mark


GET FREE 5GB ONLINE STORAGE - Safely store your documents, photos and music 
online!
Visit http://www.inbox.com/storage to find out more!

[jira] Updated: (STDCXX-426) infinite loop in exec utility

[Mark Brown (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Brown updated STDCXX-426:
--

Attachment: strace.run-21.cwchar.log

Attached partial strace output of running exec 21.cwchar.

> infinite loop in exec utility
> -
>
> Key: STDCXX-426
> URL: https://issues.apache.org/jira/browse/STDCXX-426
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Test Driver
>Affects Versions: 4.2
> Environment: gcc 3.4.6 on Red Hat Advanced Server 4, 12D (shared, 
> wide, optimized, thread-safe) build
>Reporter: Mark Brown
>Priority: Critical
> Fix For: 4.2
>
> Attachments: strace.run-21.cwchar.log
>
>
> Copied from 
> http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200705.mbox/[EMAIL
>  PROTECTED]
>  Original Message 
> Subject: infinite loop in exec
> Date: Wed, 23 May 2007 14:28:47 -0600
> From: Martin Sebor <[EMAIL PROTECTED]>
> Reply-To: stdcxx-dev@incubator.apache.org
> Organization: Rogue Wave Software
> To: stdcxx-dev@incubator.apache.org
> I'm running into an (almost?) infinite loop when running some
> of our tests under the exec utility on Linux (in a 12D build
> with gcc 3.4.6 on Red Hat Advanced Server 4, I haven't tried
> other configurations). The initial output of strace for one
> of the tests, 21.cwchar, is in the attached file. The test
> by itself runs fine to completion and doesn't produce any
> unusual output (no NULs).
> Andrew, when you have a chance, can you take a look at it?
> If that's not going to be soon let me know if I should open
> an issue.
> Martin

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-426) infinite loop in exec utility

[Mark Brown (JIRA)]

infinite loop in exec utility
-

 Key: STDCXX-426
 URL: https://issues.apache.org/jira/browse/STDCXX-426
 Project: C++ Standard Library
  Issue Type: Bug
  Components: Test Driver
Affects Versions: 4.2
 Environment: gcc 3.4.6 on Red Hat Advanced Server 4, 12D (shared, 
wide, optimized, thread-safe) build
Reporter: Mark Brown
Priority: Critical
 Fix For: 4.2


Copied from 
http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200705.mbox/[EMAIL
 PROTECTED]

 Original Message 
Subject: infinite loop in exec
Date: Wed, 23 May 2007 14:28:47 -0600
From: Martin Sebor <[EMAIL PROTECTED]>
Reply-To: stdcxx-dev@incubator.apache.org
Organization: Rogue Wave Software
To: stdcxx-dev@incubator.apache.org

I'm running into an (almost?) infinite loop when running some
of our tests under the exec utility on Linux (in a 12D build
with gcc 3.4.6 on Red Hat Advanced Server 4, I haven't tried
other configurations). The initial output of strace for one
of the tests, 21.cwchar, is in the attached file. The test
by itself runs fine to completion and doesn't produce any
unusual output (no NULs).

Andrew, when you have a chance, can you take a look at it?
If that's not going to be soon let me know if I should open
an issue.

Martin


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-425) remove #include from example programs

[Mark Brown (JIRA)]

remove #include  from example programs
--

 Key: STDCXX-425
 URL: https://issues.apache.org/jira/browse/STDCXX-425
 Project: C++ Standard Library
  Issue Type: Improvement
  Components: Examples
Affects Versions: 4.1.3
Reporter: Mark Brown


I was trying to use the stdcxx example programs to benchmark compilation and 
link speeds against other libraries (g++, STLport) but the examples only 
compile with stdcxx because they each include an  header. I tried 
removing the #include directive from several of the examples to see if they 
would still compile and they all did. It would be nice to remove the header and 
make the examples compile with other C++ standard libraries as well.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: svn commit: r537492 - /incubator/stdcxx/trunk/doc/stdlibref/money-get.html

[Mark Brown]

Okay, after some initial technical difficulties (sorry about the messed up 
submissions) I opened two issues:

22.locale.money.get.cpp doesn't test international monetary formats 
(https://issues.apache.org/jira/browse/STDCXX-413)
and money_get fails to parse currency in international format 
(https://issues.apache.org/jira/browse/STDCXX-412).

-- Mark


> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Sat, 12 May 2007 15:42:16 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: svn commit: r537492 -
> /incubator/stdcxx/trunk/doc/stdlibref/money-get.html
> 
> Mark Brown wrote:
>>> -Original Message-
>>> From: [EMAIL PROTECTED]
>>> Sent: Sat, 12 May 2007 14:09:34 -0600
>>> To: stdcxx-dev@incubator.apache.org
>>> Subject: Re: svn commit: r537492 -
>>> /incubator/stdcxx/trunk/doc/stdlibref/money-get.html
>>> 
>>> Mark Brown wrote:
>>>> Martin,
>>>> 
>>>> Thanks for fixing it! I have a question about the new code: Could you
>>>> show an example of an international monetary string that would be
>>>> correctly parsed by the facet? I tried a few but none of them could be
>>>> parsed. For instance, "USD 1234" gives this output:
>>>> USD 1234 --> "" --> 0
>>>> The same happens with g++ and STLport so I suspect I must be doing
>>>> something wrong. Removing the space between the currency symbol and
>>>> the
>>>> number didn't make a difference.
>>> Hmm, I guess I should have tested the internationalized behavior before
>>> I put it in. I think the code is correct as is and your input should be
>>> correctly parsed by the facet (and produce 1234 on output). I'm not
>>> sure
>>> what's going on. Stepping through the code it looks like the money_get
>>> facet ends up retrieving the wrong specialization of moneypunct, i.e.,
>>> moneypunct when it needs moneypunct. What's
>>> puzzling is that both libstdc++ and STLport behave the same. It seems
>>> like too much of a coincidence for all three implementations to suffer
>>> from the same bug.
>>> 
>>> In any event, thanks for bringing it to our attention! Can you open an
>>> issue for this as well so we don't forget to investigate it in case I
>>> don't get around to it soon?
>> 
>> I can certainly do that. I should also mention that while investigating
>> this problem I found a test that's supposed to test this functionality:
>> 22.locale.money.get.cpp. The test fails 20 out of 1934 assertions but
>> none of them look like they have anything to do with parsing
>> international monetary values. It doesn't look like they are being
>> tested at all...
> 
> Yeah, I noticed it too. I'm in the process of enhancing the test to
> exercise the international formats as well. If you don't mind creating
> another issue for the test, just for tracking purposes, that would be
> swell!
> 
> Martin


GET FREE 5GB ONLINE STORAGE - Safely store your documents, photos and music 
online!
Visit http://www.inbox.com/storage to find out more!

[jira] Updated: (STDCXX-412) money_get fails to parse currency in international format

[Mark Brown (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Brown updated STDCXX-412:
--

Summary: money_get fails to parse currency in international format  (was: 
num_get fails to parse currency in international format)

Corrected the name of the facet (it's money_get, not num_get). Doh!

> money_get fails to parse currency in international format
> -
>
> Key: STDCXX-412
> URL: https://issues.apache.org/jira/browse/STDCXX-412
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 22. Localization
>Affects Versions: 4.1.3
> Environment: gcc 4.1.1 on Linux
>Reporter: Mark Brown
>
> The example program money_get fails when extractinng monetary values in 
> international format such as "USD 1234" probably because of a bug in the 
> library. From 
> http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200705.mbox/[EMAIL
>  PROTECTED]:
> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Sat, 12 May 2007 14:09:34 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: svn commit: r537492 - 
> /incubator/stdcxx/trunk/doc/stdlibref/money-get.html
> Mark Brown wrote:
> > Martin,
> > 
> > Thanks for fixing it! I have a question about the new code: Could you show 
> > an example of an international monetary string that would be correctly 
> > parsed by the facet? I tried a few but none of them could be parsed. For 
> > instance, "USD 1234" gives this output:
> > USD 1234 --> "" --> 0
> > The same happens with g++ and STLport so I suspect I must be doing 
> > something wrong. Removing the space between the currency symbol and the 
> > number didn't make a difference.
> Hmm, I guess I should have tested the internationalized behavior before
> I put it in. I think the code is correct as is and your input should be
> correctly parsed by the facet (and produce 1234 on output). I'm not sure
> what's going on. Stepping through the code it looks like the money_get
> facet ends up retrieving the wrong specialization of moneypunct, i.e.,
> moneypunct when it needs moneypunct. What's
> puzzling is that both libstdc++ and STLport behave the same. It seems
> like too much of a coincidence for all three implementations to suffer
> from the same bug.
> In any event, thanks for bringing it to our attention! Can you open an
> issue for this as well so we don't forget to investigate it in case I
> don't get around to it soon?
> Thanks
> Martin

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (STDCXX-413) 22.locale.money.get.cpp doesn't test international monetary formats

[Mark Brown (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STDCXX-413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Brown updated STDCXX-413:
--

  Component/s: Tests
  Description: 
The test 22.locale.money.get.cpp doesn't exercise international monetary 
formats. See:

-Original Message-
From: [EMAIL PROTECTED]
Sent: Sat, 12 May 2007 15:42:16 -0600
To: stdcxx-dev@incubator.apache.org
Subject: Re: svn commit: r537492 - 
/incubator/stdcxx/trunk/doc/stdlibref/money-get.html

Mark Brown wrote:
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> Sent: Sat, 12 May 2007 14:09:34 -0600
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: svn commit: r537492 -
>> /incubator/stdcxx/trunk/doc/stdlibref/money-get.html
>>
>> Mark Brown wrote:
>>> Martin,
>>>
>>> Thanks for fixing it! I have a question about the new code: Could you
>>> show an example of an international monetary string that would be
>>> correctly parsed by the facet? I tried a few but none of them could be
>>> parsed. For instance, "USD 1234" gives this output:
>>> USD 1234 --> "" --> 0
>>> The same happens with g++ and STLport so I suspect I must be doing
>>> something wrong. Removing the space between the currency symbol and the
>>> number didn't make a difference.
>> Hmm, I guess I should have tested the internationalized behavior before
>> I put it in. I think the code is correct as is and your input should be
>> correctly parsed by the facet (and produce 1234 on output). I'm not sure
>> what's going on. Stepping through the code it looks like the money_get
>> facet ends up retrieving the wrong specialization of moneypunct, i.e.,
>> moneypunct when it needs moneypunct. What's
>> puzzling is that both libstdc++ and STLport behave the same. It seems
>> like too much of a coincidence for all three implementations to suffer
>> from the same bug.
>>
>> In any event, thanks for bringing it to our attention! Can you open an
>> issue for this as well so we don't forget to investigate it in case I
>> don't get around to it soon?
> 
> I can certainly do that. I should also mention that while investigating this 
> problem I found a test that's supposed to test this functionality: 
> 22.locale.money.get.cpp. The test fails 20 out of 1934 assertions but none of 
> them look like they have anything to do with parsing international monetary 
> values. It doesn't look like they are being tested at all...

Yeah, I noticed it too. I'm in the process of enhancing the test to
exercise the international formats as well. If you don't mind creating
another issue for the test, just for tracking purposes, that would be
swell!

Martin

Affects Version/s: 4.1.3
  Summary: 22.locale.money.get.cpp doesn't test international 
monetary formats  (was: 22.locale.money.get.cpp doesn')

Finishing an accidentally submitted incomplete issue.

> 22.locale.money.get.cpp doesn't test international monetary formats
> ---
>
> Key: STDCXX-413
> URL: https://issues.apache.org/jira/browse/STDCXX-413
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 4.1.3
>    Reporter: Mark Brown
>
> The test 22.locale.money.get.cpp doesn't exercise international monetary 
> formats. See:
> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Sat, 12 May 2007 15:42:16 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: svn commit: r537492 - 
> /incubator/stdcxx/trunk/doc/stdlibref/money-get.html
> Mark Brown wrote:
> >> -Original Message-
> >> From: [EMAIL PROTECTED]
> >> Sent: Sat, 12 May 2007 14:09:34 -0600
> >> To: stdcxx-dev@incubator.apache.org
> >> Subject: Re: svn commit: r537492 -
> >> /incubator/stdcxx/trunk/doc/stdlibref/money-get.html
> >>
> >> Mark Brown wrote:
> >>> Martin,
> >>>
> >>> Thanks for fixing it! I have a question about the new code: Could you
> >>> show an example of an international monetary string that would be
> >>> correctly parsed by the facet? I tried a few but none of them could be
> >>> parsed. For instance, "USD 1234" gives this output:
> >>> USD 1234 --> "" --> 0
> >>> The same happens with g++ and STLport so I suspect I must be doing
> >>> something wrong. Removing the space between the curre

[jira] Created: (STDCXX-412) num_get fails to parse currency in international format

[Mark Brown (JIRA)]

num_get fails to parse currency in international format
---

 Key: STDCXX-412
 URL: https://issues.apache.org/jira/browse/STDCXX-412
 Project: C++ Standard Library
  Issue Type: Bug
  Components: 22. Localization
Affects Versions: 4.1.3
 Environment: gcc 4.1.1 on Linux
Reporter: Mark Brown


The example program money_get fails when extractinng monetary values in 
international format such as "USD 1234" probably because of a bug in the 
library. From 
http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200705.mbox/[EMAIL
 PROTECTED]:

-Original Message-
From: [EMAIL PROTECTED]
Sent: Sat, 12 May 2007 14:09:34 -0600
To: stdcxx-dev@incubator.apache.org
Subject: Re: svn commit: r537492 - 
/incubator/stdcxx/trunk/doc/stdlibref/money-get.html

Mark Brown wrote:
> Martin,
> 
> Thanks for fixing it! I have a question about the new code: Could you show an 
> example of an international monetary string that would be correctly parsed by 
> the facet? I tried a few but none of them could be parsed. For instance, "USD 
> 1234" gives this output:
> USD 1234 --> "" --> 0
> The same happens with g++ and STLport so I suspect I must be doing something 
> wrong. Removing the space between the currency symbol and the number didn't 
> make a difference.

Hmm, I guess I should have tested the internationalized behavior before
I put it in. I think the code is correct as is and your input should be
correctly parsed by the facet (and produce 1234 on output). I'm not sure
what's going on. Stepping through the code it looks like the money_get
facet ends up retrieving the wrong specialization of moneypunct, i.e.,
moneypunct when it needs moneypunct. What's
puzzling is that both libstdc++ and STLport behave the same. It seems
like too much of a coincidence for all three implementations to suffer
from the same bug.

In any event, thanks for bringing it to our attention! Can you open an
issue for this as well so we don't forget to investigate it in case I
don't get around to it soon?

Thanks
Martin


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-413) 22.locale.money.get.cpp doesn'

[Mark Brown (JIRA)]

22.locale.money.get.cpp doesn'
--

 Key: STDCXX-413
 URL: https://issues.apache.org/jira/browse/STDCXX-413
 Project: C++ Standard Library
  Issue Type: Bug
Reporter: Mark Brown




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: svn commit: r537492 - /incubator/stdcxx/trunk/doc/stdlibref/money-get.html

[Mark Brown]

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Sat, 12 May 2007 14:09:34 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: svn commit: r537492 -
> /incubator/stdcxx/trunk/doc/stdlibref/money-get.html
> 
> Mark Brown wrote:
>> Martin,
>> 
>> Thanks for fixing it! I have a question about the new code: Could you
>> show an example of an international monetary string that would be
>> correctly parsed by the facet? I tried a few but none of them could be
>> parsed. For instance, "USD 1234" gives this output:
>> USD 1234 --> "" --> 0
>> The same happens with g++ and STLport so I suspect I must be doing
>> something wrong. Removing the space between the currency symbol and the
>> number didn't make a difference.
> 
> Hmm, I guess I should have tested the internationalized behavior before
> I put it in. I think the code is correct as is and your input should be
> correctly parsed by the facet (and produce 1234 on output). I'm not sure
> what's going on. Stepping through the code it looks like the money_get
> facet ends up retrieving the wrong specialization of moneypunct, i.e.,
> moneypunct when it needs moneypunct. What's
> puzzling is that both libstdc++ and STLport behave the same. It seems
> like too much of a coincidence for all three implementations to suffer
> from the same bug.
> 
> In any event, thanks for bringing it to our attention! Can you open an
> issue for this as well so we don't forget to investigate it in case I
> don't get around to it soon?

I can certainly do that. I should also mention that while investigating this 
problem I found a test that's supposed to test this functionality: 
22.locale.money.get.cpp. The test fails 20 out of 1934 assertions but none of 
them look like they have anything to do with parsing international monetary 
values. It doesn't look like they are being tested at all...

-- Mark


KEEP SPYWARE OFF YOUR COMPUTER - Protect your computer with Spyware Terminator!
Visit http://www.spywareterminator.com/install and find out more!

RE: svn commit: r537492 - /incubator/stdcxx/trunk/doc/stdlibref/money-get.html

[Mark Brown]

Martin,

Thanks for fixing it! I have a question about the new code: Could you show an 
example of an international monetary string that would be correctly parsed by 
the facet? I tried a few but none of them could be parsed. For instance, "USD 
1234" gives this output:
USD 1234 --> "" --> 0
The same happens with g++ and STLport so I suspect I must be doing something 
wrong. Removing the space between the currency symbol and the number didn't 
make a difference.

-- Mark


> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Sat, 12 May 2007 17:32:56 -
> To: [EMAIL PROTECTED]
> Subject: svn commit: r537492 -
> /incubator/stdcxx/trunk/doc/stdlibref/money-get.html
> 
> Author: sebor
> Date: Sat May 12 10:32:55 2007
> New Revision: 537492
> 
> URL: http://svn.apache.org/viewvc?view=rev&rev=537492
> Log:
> 2007-05-12  Martin Sebor  <[EMAIL PROTECTED]>
> 
>   STDCXX-411
>   * money-get.html: Updated example program to (closely) match
>   the latest version of the program in svn and to match shown
>   output.
> 
> Modified:
> incubator/stdcxx/trunk/doc/stdlibref/money-get.html
> 
> Modified: incubator/stdcxx/trunk/doc/stdlibref/money-get.html
> URL:
> http://svn.apache.org/viewvc/incubator/stdcxx/trunk/doc/stdlibref/money-get.html?view=diff&rev=537492&r1=537491&r2=537492
> ==
> --- incubator/stdcxx/trunk/doc/stdlibref/money-get.html (original)
> +++ incubator/stdcxx/trunk/doc/stdlibref/money-get.html Sat May 12
> 10:32:55 2007
> @@ -165,54 +165,53 @@
>  #include    // for cout, endl
>  #include    // for istreambuf_iterator
> 
> -#include 
> +int main (int argc, char *argv[])
> +{
> +// Get the monetary string and locale from the argument vector.
> +const char* const buffer  = 1 < argc ? argv [1] : "$1,234.6789";
> +const char* const locname = 2 < argc ? argv [2] : "en_US";
> +const boolintl= 3 < argc;
> 
> +std::string smon;
> +long double fmon = 0.0;
> 
> -int main ()
> -{
> -typedef std::istreambuf_iterator -std::char_traits > Iter;
> -
> -const std::string buffer ("$100.02");
> -std::string dest;
> -long double ldest;
> -std::ios_base::iostate state;
> -Iter end;
> -
> -// Retrieve the money_get facet from the global locale.
> -const std::money_get &mgf =
> -std::use_facet
> >(std::locale
> - ());
> +std::ios_base::iostate state = std::ios_base::goodbit;
> +
> +// Retrieve the money_get facet from the named locale.
> +const std::locale loc (locname);
> +
> +typedef std::istreambuf_iterator Iter;
> +typedef std::money_get MoneyGet;
> +
> +const MoneyGet &mgf = std::use_facet(loc);
> 
>  {
> -// Build an istringstream from the buffer and construct
> -// a beginning iterator on it.
> +// Build an istringstream object from the buffer
> +// and imbue the locale in it.
>  std::istringstream ins (buffer);
> -Iter begin (ins);
> +ins.imbue (loc);
> 
> -// Get a string representation of the monetary value
> -mgf.get (begin, end, false, ins, state, dest);
> +// Get a string representation of the monetary value.
> +mgf.get (ins, Iter (), intl, ins, state, smon);
>  }
>  {
> -// Build another istringstream from the buffer, etc.
> -// so we have an iterator pointing to the beginning
>  std::istringstream ins (buffer);
> -Iter begin (ins);
> +ins.imbue (loc);
> 
> -// Get a a long double representation of the monetary
> -   value
> -mgf.get (begin, end, false, ins, state, ldest);
> +// Get a floating point representation of the monetary value.
> +mgf.get (ins, Iter (), intl, ins, state, fmon);
>  }
> 
> -std::cout << buffer << " --> "
> -  << dest << " --> " << ldest <<
> std::endl;
> +// Output the original sequence and its string and floating point
> +// representations.
> +std::cout << buffer << " --> \"" << smon
> << "\" --> " << fmon << '\n';
> 
> -// return 0 on success, non-zero on failure
> +// Return 0 on success, non-zero on failure.
>  return !(std::ios_base::eofbit == state);
>  }
> 
>  Program Output:
> -$100.02 --> 10002 --> 10002
> +$1,234.6789 --> "123467" --> 123467
>  
>  See Also
>  locale,  HREF="facets.html">Facets,  HREF="money-put.html">money_put,  HREF="moneypunct.html">moneypunct


ONE-CLICK WEBMAIL ACCESS - Easily monitor & access your email accounts!
Visit http://www.inbox.com/notifier and check it out!

Re: money_get example output

[Mark Brown]

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Fri, 11 May 2007 16:54:37 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: money_get example output
> 
> Mark Brown wrote:
>> Hi all,
>> 
>> Out of curiosity I tried compiling and running the example from the
>> money_get page with stdcxx on Linux but the output is different than the
>> documentation shows. So I tried it with g++ and the output is different
>> still. Is the documentation incorrect or is there a bug in the library?
>> Can someone explain what the correct output should be?
>> 
>> $ ./money_get-stdcxx
>> $100.02 -->  --> 0e-2175
>> $ ./money_get-g++
>> $100.02 -->  --> 1.432e-3754
>> 
>> The example program is on this page:
>> http://incubator.apache.org/stdcxx/doc/stdlibref/money-get.html
> 
> I think the problem is that the example code on the documentation
> page doesn't set the locale. The real example (i.e., the actual
> program) does: it sets it to the English US locale. The code is
> here:
> http://svn.apache.org/repos/asf/incubator/stdcxx/trunk/examples/manual/moneyget.cpp
> 
> The reason why stdcxx and libstdc++ produce different output in
> the default "C" locale is in all likelihood because the facet
> fails to store a value in the uninitialized variable and the
> example ends up writing out bogus bits.
> 
> Can you please open a new Documentation issue for this?

Done! The issue is https://issues.apache.org/jira/browse/STDCXX-411

-- Mark

[jira] Created: (STDCXX-411) documented money_get example output doesn't match real output

[Mark Brown (JIRA)]

documented money_get example output doesn't match real output
-

 Key: STDCXX-411
 URL: https://issues.apache.org/jira/browse/STDCXX-411
 Project: C++ Standard Library
  Issue Type: Bug
  Components: Documentation
Affects Versions: 4.1.3
Reporter: Mark Brown


-Original Message-
From: [EMAIL PROTECTED]
Sent: Fri, 11 May 2007 16:54:37 -0600
To: stdcxx-dev@incubator.apache.org
Subject: Re: money_get example output

Mark Brown wrote:
> Hi all,
> 
> Out of curiosity I tried compiling and running the example from the money_get 
> page with stdcxx on Linux but the output is different than the documentation 
> shows. So I tried it with g++ and the output is different still. Is the 
> documentation incorrect or is there a bug in the library? Can someone explain 
> what the correct output should be?
> 
> $ ./money_get-stdcxx
> $100.02 -->  --> 0e-2175
> $ ./money_get-g++
> $100.02 -->  --> 1.432e-3754
> 
> The example program is on this page: 
> http://incubator.apache.org/stdcxx/doc/stdlibref/money-get.html

I think the problem is that the example code on the documentation
page doesn't set the locale. The real example (i.e., the actual
program) does: it sets it to the English US locale. The code is
here:
http://svn.apache.org/repos/asf/incubator/stdcxx/trunk/examples/manual/moneyget.cpp

The reason why stdcxx and libstdc++ produce different output in
the default "C" locale is in all likelihood because the facet
fails to store a value in the uninitialized variable and the
example ends up writing out bogus bits.

Can you please open a new Documentation issue for this?

FWIW, copying the source code of each example program into the
docs and keeping the two in sync is a maintenance headache. We
should find a better way to do this.

One possibility for dealing with this is to get rid of the code
and replace it with a link to the .cpp file in Subversion. That
alone probably isn't the most user-friendly solution.

A variation on this approach that might be better is to run
a script on the documentation sources after checking them out
of Subversion on the Apache Web server and replace the links
mentioned above with the up-to-date source code of each example
extracted at the same time out of the repository.

Can anyone think of any other ways to keep things in sync, or
of any further improvements to the process?

Martin


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: EASTL

[Mark Brown]

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Thu, 10 May 2007 13:56:11 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: EASTL
> 
> Eric Lemings wrote:
>> 
>> Since Apache STDCXX is touted as one of, if not the, best standard C++
>> library in terms of performance, I thought the following document would
>> be especially interesting read for performance-minded STDCXX maintainers
>> and users.
>> 
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2271.html
> 
> I barely just skimmed it but it does look interesting. We started
> a benchmarking project some time ago but, unfortunately, it never
> got finished. It would be *really* helpful to resurrect and complete
> it. My very informal results I run every now and then with gcc on
> Linux and Solaris indicate that in the area of iostreams stdcxx is
> up to 25% faster than GNU libstdc++ and on par with stdio. I would
> very much like to see a comprehensive comparison of other heavily
> used components, including string and the other containers. Any
> volunteers? ;-)

I would be happy to do some light benchmarking and post my results here if you 
think it would be useful. Unfortunately, I don't think I can commit to a 
comprehensive project to cover the whole library.

-- Mark

> 
> Martin

money_get example output

[Mark Brown]

Hi all,

Out of curiosity I tried compiling and running the example from the money_get 
page with stdcxx on Linux but the output is different than the documentation 
shows. So I tried it with g++ and the output is different still. Is the 
documentation incorrect or is there a bug in the library? Can someone explain 
what the correct output should be?

$ ./money_get-stdcxx
$100.02 -->  --> 0e-2175
$ ./money_get-g++
$100.02 -->  --> 1.432e-3754

The example program is on this page: 
http://incubator.apache.org/stdcxx/doc/stdlibref/money-get.html

-- Mark


FREE ONLINE PHOTOSHARING - Share your photos online with your friends and 
family!
Visit http://www.inbox.com/photosharing to find out more!

[jira] Created: (STDCXX-410) money_base not documented

[Mark Brown (JIRA)]

money_base not documented
-

 Key: STDCXX-410
 URL: https://issues.apache.org/jira/browse/STDCXX-410
 Project: C++ Standard Library
  Issue Type: Bug
  Components: Documentation
Affects Versions: 4.1.3
Reporter: Mark Brown


The money_get Class reference pag: 
http://incubator.apache.org/stdcxx/doc/stdlibref/money-get.html is missing 
documentation for the money_base class.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

RE: TR1 Development Plan

[Mark Brown]

Hi Eric,

I don't know if there is a development plan per se except for a number of Jira 
issues (one for each section of the TR). Your suggestion to make the extensions 
available in namespace std sounds like a fine idea to me.

I am also interested in the TR1 extensions but I haven't experimented with 
those in stdcxx yet. I have spent most of my time so far trying to understand 
the stdcxx build process and experimenting with the tests but as soon as I feel 
comfortable making more extensive changes I would like to offer my help with 
the new hash-based containers.

-- Mark

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Mon, 9 Apr 2007 10:14:01 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: TR1 Development Plan
> 
> Hello all,
> 
> I was wondering if there was a TR1 development plan in place, informal
> or otherwise, for TR1 development.  I noticed that there is some
> existing TR1 classes but the headers are rather old and they reside in
> the transitional std::tr1 namespace.
> 
> I was thinking perhaps integrate the TR1 extensions directly into their
> eventual namespace and headers and enable or disable the TR1 extensions
> with a compile-time macro.  If the _RWSTD_ENABLE_TR1 or some such macro
> is defined (initially undefined by default), then the TR1 classes will
> be defined.
> 
> If anyone has thoughts on the issue, please post them.  Also if there
> are docs somewhere that outline the plan for TR1, please point them out.
> 
> Thanks,
> Eric.


FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your 
desktop!
Check it out at http://www.inbox.com/marineaquarium

Re: strange characters in test output on gnome-terminal

[Mark Brown]

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Mon, 02 Apr 2007 13:09:18 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: strange characters in test output on gnome-terminal
> 
> What version of Gnome terminal are you using? I couldn't reproduce
> this behavior with Gnome gnome-terminal 2.2.2 (running on Linux).
> I get monochromatic output with no garbage in it suggesting that
> the terminal isn't capable of recognizing the VT100 escape
> sequences (the test driver should be able to detect it and avoid
> using the sequences).

Mine is 2.16.0. It displays ls colors with no problems, it only has trouble 
with the output of the tests, not just in the final table but in all output as 
well. For instance:

$ ./23.list.assign 
# ?[30;mINFO (S1) (10 lines):
# TEXT: 
# COMPILER: gcc 4.1.1, __VERSION__ = "4.1.1 20061011 (Red Hat 4.1.1-30)"
# ENVIRONMENT: amd64/LP64 running linux-elf (unknown release) with glibc 2.5
# FILE: 23.list.assign.cpp
# COMPILED: Apr  3 2007, 13:19:41
# COMMENT: 


# CLAUSE: lib.list.assign

# ?[30;mINFO (S1) (3 lines):
# TEXT: std::list::assign(size_type, const_reference)
# CLAUSE: lib.list.assign
...

-- Mark


> 
> Martin
> 
> Scott Zhong wrote:
>> I am seeing these characters using gnome on opensuse.
>> 
>> Yu (Scott) Zhong
>> 
>> 
>> 
>> -Original Message-
>> From: Mark Brown [mailto:[EMAIL PROTECTED]
>> Sent: Sat 3/31/2007 3:57 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: strange characters in test output on gnome-terminal
>> 
>> Hi!
>> 
>> After I switched to a different terminal (gnome-terminal) I see these
>> strange characters when I run stdcxx tests. It seems as though the
>> terminal doesn't interpret the color commands correctly. Has anyone
>> experienced anything like this? Is there a way to get the correct output
>> with this type of terminal, either with colors working or plain?
>> 
>> # +---+--+--+--+
>> # | DIAGNOSTIC|  ACTIVE  |   TOTAL  | INACTIVE |
>> # +---+--+--+--+
>> # | (S1) INFO |?[30;m   53 |   53 |   0% |
>> # | (S2) NOTE |0 |   52 | 100% |
>> # | (S7) ASSERTION|0 | 2042 | 100% |
>> # +---+--+--+--+
>> 
>> -- Mark
>> 
>> 
>> Invite Friends to View Your Photo Album and
>> ... Win Free iPods, Movie Tickets or 1GB of Storage.
>> Check it out http://www.inbox.com/win_iPod
>> 

strange characters in test output on gnome-terminal

[Mark Brown]

Hi!

After I switched to a different terminal (gnome-terminal) I see these strange 
characters when I run stdcxx tests. It seems as though the terminal doesn't 
interpret the color commands correctly. Has anyone experienced anything like 
this? Is there a way to get the correct output with this type of terminal, 
either with colors working or plain?

# +---+--+--+--+
# | DIAGNOSTIC|  ACTIVE  |   TOTAL  | INACTIVE |
# +---+--+--+--+
# | (S1) INFO |?[30;m   53 |   53 |   0% |
# | (S2) NOTE |0 |   52 | 100% |
# | (S7) ASSERTION|0 | 2042 | 100% |
# +---+--+--+--+

-- Mark


Invite Friends to View Your Photo Album and 
... Win Free iPods, Movie Tickets or 1GB of Storage. 
Check it out http://www.inbox.com/win_iPod

[PATCH] clean up unused variable warnings in new list tests

[Mark Brown]

I just noticed the new list tests that went in today -- they look like a lot of 
work! -- and started going through them to see how they could be enhanced to 
test the new container member functions. All the tests compile just fine but a 
couple of them spit out lots of warnings for the same unused variable. I would 
like to clean them up before I make any changes. For instance, here is one I 
get for the list assign test:

gcc -c -I/home/mbrown/stdcxx/include/ansi -D_RWSTDDEBUG
-I/home/mbrown/stdcxx/include -I/home/mbrown/stdcxx-gcc-4.1.1-11s/include 
-I/home/mbrown/stdcxx/../rwtest/include -I/home/mbrown/stdcxx/tests/include  
-pedantic -nostdinc++ -g  -W -Wall -Wcast-qual -Winline -Wshadow 
-Wwrite-strings -Wno-long-long -Wcast-align   
/home/mbrown/stdcxx/tests/containers/23.list.assign.cpp
/home/mbrown/stdcxx/tests/containers/23.list.assign.cpp: In member function 
‘List& AssignRangeOverload::operator()(List&, const 
ContainerTestCaseData&) const [with List = 
std::list > >, Iterator = 
std::reverse_iterator<__rw::__rw_debug_iter > >, std::__rw_list_iter, std::__rw_list_iter > >]’:
/home/mbrown/stdcxx/tests/containers/23.list.assign.cpp:556:   instantiated 
from here
/home/mbrown/stdcxx/tests/containers/23.list.assign.cpp:249: warning: unused 
variable ‘tcase’

And here is the patch that makes the warnings go away:

Index: /home/mbrown/stdcxx/tests/containers/23.list.insert.cpp
===
--- /home/mbrown/stdcxx/tests/containers/23.list.insert.cpp (revision 
523168)
+++ /home/mbrown/stdcxx/tests/containers/23.list.insert.cpp (working copy)
@@ -383,8 +383,6 @@
 operator() (List &lst, 
 const ContainerTestCaseData& tdata) const {
 
-const ContainerTestCase &tcase = tdata.tcase_;
-
 // create a pair of iterators into the list object being modified
 ListIter first1 (lst.begin ());
 _rw_advance (first1, tdata.off1_);
@@ -415,8 +413,6 @@
 operator() (List &lst, 
 const ContainerTestCaseData& tdata) const {
 
-const ContainerTestCase &tcase = tdata.tcase_;
-
 // create a pair of iterators into the list object being modified
 ListIter first1 (lst.begin ());
 _rw_advance (first1, tdata.off1_);
@@ -460,8 +456,6 @@
 operator() (List& lst,
 const ContainerTestCaseData& tdata) const {
 
-const ContainerTestCase &tcase = tdata.tcase_;
-
 ListIter first1 (lst.begin ());
 _rw_advance (first1, tdata.off1_);
 
Index: /home/mbrown/stdcxx/tests/containers/23.list.assign.cpp
===
--- /home/mbrown/stdcxx/tests/containers/23.list.assign.cpp (revision 
523168)
+++ /home/mbrown/stdcxx/tests/containers/23.list.assign.cpp (working copy)
@@ -246,8 +246,6 @@
 operator() (List &lst, 
 const ContainerTestCaseData& tdata) const {
 
-const ContainerTestCase &tcase = tdata.tcase_;
-
 bool reverse_iter = ListIds::ReverseIterator == tdata.func_.iter_id_
 || ListIds::ConstReverseIterator == tdata.func_.iter_id_;

And the ChangeLog entry to go with it:

2007-03-27  Mark Brown  <[EMAIL PROTECTED]>

* 23.list.insert.cpp (InsertRange, InsertRangeOverload,
InsertRangePtrOverload): Removed unused variable: tcase.
* 23.list.assign (AssignRangeOverload): Same.

-- Mark

[jira] Commented: (STDCXX-364) [gcc/Linux] std::tm not declared in

[Mark Brown (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483014
 ] 

Mark Brown commented on STDCXX-364:
---

I get the same error with gcc 3.4.4 on Cygwin.

> [gcc/Linux] std::tm not declared in 
> 
>
> Key: STDCXX-364
> URL: https://issues.apache.org/jira/browse/STDCXX-364
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 21. Strings
>Affects Versions: 4.1.3
> Environment: Linux, gcc 3.4.6 - 4.1.2 
>Reporter: Scott (Yu) Zhong
>
> getting this error:
> /home/scottz/stdcxx/tests/strings/21.cwchar.cpp:568: error: reference to 'tm' 
> is ambiguous
> /usr/include/../include/time.h:135: error: candidates are: struct tm
> /home/scottz/stdcxx/tests/strings/21.cwchar.cpp:550: error: 
> struct Fallback::tm
> /home/scottz/stdcxx/tests/strings/21.cwchar.cpp:568: error: reference to 'tm' 
> is ambiguous
> /usr/include/../include/time.h:135: error: candidates are: struct tm
> /home/scottz/stdcxx/tests/strings/21.cwchar.cpp:550: error: 
> struct Fallback::tm
> /home/scottz/stdcxx/tests/strings/21.cwchar.cpp:568: error: 'tm' does not 
> name a type
> /home/scottz/stdcxx/tests/strings/21.cwchar.cpp:577: error: 'test_tm' in 
> namespace 'std::Nested' does not name a type
> -
> Martin Sebor [EMAIL PROTECTED]
> I was able to reproduce the same error with gcc 3.4.6.
> The purpose of the test is to verify the conformance of the  header 
> WRT namespace cleanliness (i.e., that symbols like struct tm are defined in 
> namespace std and not also in the global scope). The test is designed to fail 
> at runtime (via assertions) rather than at compile time but it looks like the 
> implementation of the test (or maybe even its
> design) is broken. In any case, the fact that the test doesn't compile 
> suggests there is a problem with the header.
> The compilation errors for the simple program below confirm this. Can you 
> open an issue for this problem and reference this thread in the archive in 
> the issue?
> $ cat t.cpp && nice make t
> #include 
> int main ()
> {
>  std::tm tmb = { 0 };
> }
> gcc -c -I/amd/devco/sebor/stdcxx/include/ansi -D_RWSTDDEBUG 
> -I/amd/devco/sebor/stdcxx/include -I/build/sebor/stdcxx-gcc-3.4.6-11S/include
> -I/amd/devco/sebor/stdcxx/../rwtest
> -I/amd/devco/sebor/stdcxx/../rwtest/include
> -I/amd/devco/sebor/stdcxx/tests/include  -pedantic -nostdinc++ -g  -W -Wall 
> -Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long 
> -Wcast-align   t.cpp
> t.cpp: In function `int main()':
> t.cpp:5: error: `tm' is not a member of `std'
> t.cpp:5: error: expected `;' before "tmb"
> make: *** [t.o] Error 1
> Thanks
> Martin
> $ cat t.cpp && nice make t
> #include 
> int main ()
> {
>  std::tm tmb = { 0 };
> }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (STDCXX-351) [gcc 3.4.6] error on static const int expression as an array dimension in template code

[Mark Brown (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12483012
 ] 

Mark Brown commented on STDCXX-351:
---

The test compiles now so your change must have fixed it.

> [gcc 3.4.6] error on static const int expression as an array dimension in 
> template code
> ---
>
> Key: STDCXX-351
> URL: https://issues.apache.org/jira/browse/STDCXX-351
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: External
> Environment: gcc 3.4.6
>Reporter: Martin Sebor
> Assigned To: Martin Sebor
> Fix For: 4.2
>
>
> The well-formed program below fails to compile with gcc 3.4.6 (gcc 4.1 does 
> fine):
> $ cat t.cpp && gcc --version && gcc -pedantic t.cpp
> template  struct S { static const int N = 1; };
> template 
> void foo () {
> static const int N = S::N;
> static int a [S::N];
> static int b [N];
> }
> int main () { foo(); }
> gcc (GCC) 3.4.6 20060404 (Red Hat 3.4.6-3)
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> t.cpp: In function `void foo()':
> t.cpp:7: error: ISO C++ forbids variable-size array `b'

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [PATCH] Re: new container member functions cbegin() and cend()

[Mark Brown]

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Wed, 21 Mar 2007 16:12:57 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [PATCH] Re: new container member functions cbegin() and
> cend()
> 
> Sorry for dropping the ball on reviewing this patch.
> 
> The changes look good to me. The two things that are missing
> and that we can't commit the patch without are: 1) tests and
> 2) a ChangeLog entry.
> 
> We haven't ported all the container tests to the new driver
> so you won't be able to simply enhance existing tests to
> exercise all the functions but you should be able to do so
> for deque, list, and string. Take a look at the tests for
> these three containers to see if you can figure out how to
> enhance them. If you need help feel free to ask. One of us
> (presumably Farid, as he has the most experience with these
> tests) should be able to answer your questions.

I would be happy to enhance the tests but all I could find are these:

23.bitset.cons.cpp
23.bitset.cpp
23.deque.iterators.cpp
23.deque.modifiers.cpp
23.deque.special.cpp
23.vector.capacity.cpp
23.vector.cons.cpp
23.vector.modifiers.cpp

There are no tests for list and I'm not sure how to enhance the deque
tests. Am I looking in the right place?

-- Mark

> 
> As for the other containers, we'll need to remember to add
> tests for these new functions when we get around to porting
> (or writing from scratch) the tests for those.
> 
> Martin
> 
> Mark Brown wrote:
>> How frustrating!
>> 
>> Here it is again, this time inline:
>> 
>> Index: /home/mbrown/stdcxx/include/map
>> ===
>> --- /home/mbrown/stdcxx/include/map  (revision 516799)
>> +++ /home/mbrown/stdcxx/include/map  (working copy)
>> @@ -167,6 +167,10 @@
>>  return _C_rep.begin ();
>>  }
>> 
>> +const_iterator cbegin () const {
>> +return _C_rep.begin ();
>> +}
>> +
>>  iterator end () {
>>  return _C_rep.end ();
>>  }
>> @@ -175,6 +179,10 @@
>>  return _C_rep.end ();
>>  }
>> 
>> +const_iterator cend () const {
>> +return _C_rep.end ();
>> +}
>> +
>>  reverse_iterator rbegin () {
>>  return _C_rep.rbegin ();
>>  }
>> @@ -183,6 +191,10 @@
>>  return _C_rep.rbegin ();
>>  }
>> 
>> +const_reverse_iterator crbegin () const {
>> +return _C_rep.rbegin ();
>> +}
>> +
>>  reverse_iterator rend () {
>>  return _C_rep.rend ();
>>  }
>> @@ -191,6 +203,10 @@
>>  return _C_rep.rend ();
>>  }
>> 
>> +const_reverse_iterator crend () const {
>> +return _C_rep.rend ();
>> +}
>> +
>>  bool empty () const {
>>  return _C_rep.empty ();
>>  }
>> Index: /home/mbrown/stdcxx/include/set
>> ===
>> --- /home/mbrown/stdcxx/include/set  (revision 516799)
>> +++ /home/mbrown/stdcxx/include/set  (working copy)
>> @@ -160,12 +160,16 @@
>>  //
>>  iterator begin  ()   { return _C_rep.begin ();
>> }
>>  const_iterator   begin  () const { return _C_rep.begin ();
>> }
>> +const_iterator   cbegin () const { return _C_rep.begin ();
>> }
>>  iterator end()   { return _C_rep.end ();
>> }
>>  const_iterator   end() const { return _C_rep.end ();
>> }
>> +const_iterator   cend   () const { return _C_rep.end ();
>> }
>>  reverse_iterator rbegin ()   { return _C_rep.rbegin ();
>> }
>>  const_reverse_iterator   rbegin () const { return _C_rep.rbegin ();
>> }
>> +const_reverse_iterator   crbegin() const { return _C_rep.rbegin ();
>> }
>>  reverse_iterator rend   ()   { return _C_rep.rend ();
>> }
>>  const_reverse_iterator   rend   () const { return _C_rep.rend ();
>> }
>> +const_reverse_iterator   crend  () const { return _C_rep.rend ();
>> }
>> 
>>  //
>>  // capacity
>> Index: /home/mbrown/stdcxx/include/string
>> ===
>> --- /home/mbrown/stdcxx/include/string   (revision 516799)
>> +++ /home/mbrown/stdcxx/include/string   (working copy)
>> @@ -214,6 +214,10 @@
>>  return _C_make_iter (_C_data);
>>   

Re: [VOTE] Re: regression test suite naming convention

[Mark Brown]

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Wed, 21 Mar 2007 09:56:30 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [VOTE] Re: regression test suite naming convention
> 
> If we constrain ourselves to the proposed options, my vote is for Option
> 2.  The reason for this vote is because it allows us to more easily
> determine what regression tests need to be run for a particular change.
> 
> If we don't constrain ourselves to the proposed options, I wish to put
> forward an additional option.
> 
> Option 3:
> Put all regression tests in tests/regress/, using the following
> naming convention:
> tests/regress/.stdcxx-.cpp
> 
> This option would allow us to quickly locate all regression tests, and
> identify which section each regression test applies to without
> consulting Jira.

I also think this option is better than the one I suggested. I suppose the file 
name could include even more specific detail than just the section number such 
as the name of the container or the member function, like vector.cons and so on.

-- Mark



> 
> --Andrew Black
> 
> Martin Sebor wrote:
>> I'm not hearing any yay's or nay's on the proposed convention
>> so how about a vote to practice our consensus building skills?
>> Everyone is encouraged to vote, including non-committers.
>> 
>> Option 1:
>>   Put all regression tests in tests/regress/, naming each as
>>   follows:
>>   tests/regress/stdcxx-.cpp
>> 
>> Option 2:
>>   Mix regression tests in with the rest based on the clause
>>   in the standard and name each according to the following
>>   formula:
>>   tests//.stdcxx-.cpp
>> 
>> Martin

Re: [jira] Closed: (STDCXX-16) __rb_tree::operator=() does not store rhs' comparison object in lhs

[Mark Brown]

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Wed, 14 Mar 2007 11:44:27 -0700
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [jira] Closed: (STDCXX-16) __rb_tree::operator=() does not
> store rhs' comparison object in lhs
> 
> Farid Zaripov (JIRA) wrote:
>>  [
https://issues.apache.org/jira/browse/STDCXX-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
>> ]
>> 
>> Farid Zaripov closed STDCXX-16.
>> ---
>> 
>> 
>>> __rb_tree::operator=() does not store rhs' comparison object in lhs
> 
> Do we have a test in the test suite that exercises this? If not,
> the status should stay Resolved until one has been added.
> 
> As we discussed previously, I think it would be useful to start
> adding small test cases corresponding to each Jira issue to our
> regression test suite. Those would be in addition to the general
> tests that already are or will be put in place (duplication of
> tested functionality would be possible).
> 
> I propose tests/regress/stdcxx-NNN as the directory and file
> naming convention for these new tests.
> 
> Comments?

I like how the existing tests are organized by sections in the standard. When 
working on for example vector, it's easy to run just the container tests 
without having to worry about all the other tests. If the regression tests are 
in a separate directory people will need to remember to build and run them in 
addition to those for whatever it is they happen to be working on. Would it be 
possible to put the regression tests in the same directories as the other tests 
for the same components?

-- Mark


KEEP SPYWARE OFF YOUR COMPUTER - Protect your computer with Spyware Terminator!
Visit http://www.spywareterminator.com/install and find out more!

FW: [PATCH] Re: new container member functions cbegin() and cend()

[Mark Brown]

Martin,

Here's the original mail with the patch attached.

-- Mark


-Original Message-
From: [EMAIL PROTECTED]
Sent: Tue, 13 Mar 2007 08:27:26 -0800
To: stdcxx-dev@incubator.apache.org, stdcxx-dev@incubator.apache.org, 
stdcxx-dev@incubator.apache.org
Subject: [PATCH] Re: new container member functions cbegin() and cend()

Attached is my first attempt at a patch implementing these functions. Please 
let me know if I've missed something. The ChangeLong entry is here:

2007-03-13  Mark Brown <[EMAIL PROTECTED]>

STDCXX-335
* map (cbegin, cend, crbegin, crend): Implemented new accessor 
functions.
* set: Same.
* string: Same.
* vector: Same.
* deque: Same.
* list: Same.

-- Mark

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Sat, 10 Mar 2007 10:12:09 -0800
> To: stdcxx-dev@incubator.apache.org, stdcxx-dev@incubator.apache.org
> Subject: Re: new container member functions cbegin() and cend()
> 
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> Sent: Fri, 09 Mar 2007 13:44:49 -0700
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: new container member functions cbegin() and cend()
>> 
>> Mark Brown wrote:
>>> The next C++ standard adds a couple of new container member functions,
>>> cbegin() and cend(), that will make it easier to retrieve const
>>> iterators from non-const container objects. Are there any plans to add
>>> these functions to stdcxx?
>> 
>> I assume you're referring to the Working Draft of the Standard for
>> Programming Language C++:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf
>> 
>> and the functions are those proposed in Walter Brown's Proposal
>> to Improve const_iterator Use from C++0X:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1674.pdf
> 
> Yes, the functions from Alternative 1 are the ones I was referring
> to. They will become especially handy when the "auto" feature is
> available in compilers. Does anyone know of a compiler that
> supports this use of auto?
> 
>> 
>> I have no immediate plans to implement these functions but we
>> certainly expect and plan to implement the new C++ standard by
>> the time it comes out.
>> 
>> If you would like to submit a patch with these functions or any
>> other feature that's expected to be in the next standard you
>> are most welcome to do so. Small extensions like this one might
>> be okay for trunk. Bigger features will probably be more
>> appropriate for a yet-to-be created branch as suggested in
>> STDCXX-299: https://issues.apache.org/jira/browse/STDCXX-299
> 
> I will work on a patch.
> 
> -- Mark
> 
>> 
>> Martin
>> 
>>> 
>>> -- Mark


GET FREE 5GB EMAIL - Check out spam free email with many cool features!
Visit http://www.inbox.com/email to find out more!

Re: [PATCH] Re: new container member functions cbegin() and cend()

[Mark Brown]

gin._C_p,_C_begin._C_offset); }
+
+const_iterator begin () const {
+  return const_iterator (_C_begin._C_p, _C_begin._C_offset);
+}
+
+const_iterator cbegin () const {
+  return const_iterator (_C_begin._C_p, _C_begin._C_offset);
+}
+
 iterator   end   ()   { return _C_end; }
-const_iterator end   () const 
-{ return const_iterator(_C_end._C_p,_C_end._C_offset); }
 
+const_iterator end   () const {
+  return const_iterator(_C_end._C_p,_C_end._C_offset);
+}
+
+const_iterator cend () const {
+  return const_iterator (_C_end._C_p, _C_end._C_offset);
+}
+
 reverse_iterator   rbegin () { return reverse_iterator(end()); }
 const_reverse_iterator rbegin () const
 { 
   return const_reverse_iterator(end()); 
 }
+
+const_reverse_iterator crbegin () const { 
+  return const_reverse_iterator(end()); 
+}
+
 reverse_iterator   rend () { return reverse_iterator(begin()); }
 const_reverse_iterator rend () const
 { 
   return const_reverse_iterator(begin()); 
 }
 
+const_reverse_iterator crend () const { 
+  return const_reverse_iterator(begin()); 
+}
+
 //
 // capacity
 //
Index: /home/mbrown/stdcxx/include/deque
===
--- /home/mbrown/stdcxx/include/deque   (revision 516799)
+++ /home/mbrown/stdcxx/include/deque   (working copy)
@@ -516,6 +516,10 @@
 return _C_make_iter (_C_beg);
 }
 
+const_iterator cbegin () const {
+return _C_make_iter (_C_beg);
+}
+
 iterator end () {
 return _C_make_iter (_C_end);
 }
@@ -524,6 +528,10 @@
 return _C_make_iter (_C_end);
 }
 
+const_iterator cend () const {
+return _C_make_iter (_C_end);
+}
+
 reverse_iterator rbegin () {
 return reverse_iterator (end ());
 }
@@ -532,6 +540,10 @@
 return const_reverse_iterator (end ());
 }
 
+const_reverse_iterator crbegin () const { 
+return const_reverse_iterator (end ());
+}
+
 reverse_iterator rend () { 
 return reverse_iterator (begin ());
 }
@@ -540,6 +552,10 @@
 return const_reverse_iterator (begin ());
 }
 
+const_reverse_iterator crend () const { 
+return const_reverse_iterator (begin ());
+}
+
 bool empty () const {
 return_C_beg._C_node == _C_end._C_node
&& _C_beg._C_cur == _C_end._C_cur;
Index: /home/mbrown/stdcxx/include/list
===
--- /home/mbrown/stdcxx/include/list(revision 516799)
+++ /home/mbrown/stdcxx/include/list(working copy)
@@ -504,6 +504,10 @@
 return _C_make_iter ((*_C_node)._C_next);
 }
 
+const_iterator cbegin () const {
+return _C_make_iter ((*_C_node)._C_next);
+}
+
 iterator end () {
 return _C_make_iter (_C_node);
 }
@@ -512,6 +516,10 @@
 return _C_make_iter (_C_node);
 }
 
+const_iterator cend () const {
+return _C_make_iter (_C_node);
+}
+
 reverse_iterator rbegin () { 
 return reverse_iterator (end ());
 }
@@ -520,6 +528,10 @@
 return const_reverse_iterator (end ());
 }
 
+const_reverse_iterator crbegin () const { 
+return const_reverse_iterator (end ());
+}
+
 reverse_iterator rend () { 
 return reverse_iterator (begin ());
 }
@@ -528,6 +540,10 @@
 return const_reverse_iterator (begin ());
 }
 
+const_reverse_iterator crend () const {
+return const_reverse_iterator (begin ());
+}
+
 bool empty () const {
 return 0 == size ();
 }


-- Mark


> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Tue, 13 Mar 2007 10:33:40 -0600
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: [PATCH] Re: new container member functions cbegin() and
> cend()
> 
> Mark Brown wrote:
>> Attached is my first attempt at a patch implementing these functions.
>> Please let me know if I've missed something. The ChangeLong entry is
>> here:
> 
> Sorry Mark but the patch got stripped again.
> 
> Martin
> 
>> 
>> 2007-03-13  Mark Brown <[EMAIL PROTECTED]>
>> 
>>  STDCXX-335
>>  * map (cbegin, cend, crbegin, crend): Implemented new accessor
>> functions.
>>  * set: Same.
>>  * string: Same.
>>  * vector: Same.
>>  * deque: Same.
>>  * list: Same.
>> 
>> -- Mark
>> 
>>> -Original Message-
>>> From: [EMAIL PROTECTED]
>>> Sent: Sat, 10 Mar 2007 10:12:09 -0800
>>> To: stdcxx-dev@incubator.apache.org, stdcxx-dev@incubator.apache.org
>>> Subject: Re: new container member functions cbegin() and cend()
>>> 
>>>> -Original Message-
>>&

[PATCH] Re: new container member functions cbegin() and cend()

[Mark Brown]

Attached is my first attempt at a patch implementing these functions. Please 
let me know if I've missed something. The ChangeLong entry is here:

2007-03-13  Mark Brown <[EMAIL PROTECTED]>

STDCXX-335
* map (cbegin, cend, crbegin, crend): Implemented new accessor 
functions.
* set: Same.
* string: Same.
* vector: Same.
* deque: Same.
* list: Same.

-- Mark

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Sat, 10 Mar 2007 10:12:09 -0800
> To: stdcxx-dev@incubator.apache.org, stdcxx-dev@incubator.apache.org
> Subject: Re: new container member functions cbegin() and cend()
> 
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> Sent: Fri, 09 Mar 2007 13:44:49 -0700
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: new container member functions cbegin() and cend()
>> 
>> Mark Brown wrote:
>>> The next C++ standard adds a couple of new container member functions,
>>> cbegin() and cend(), that will make it easier to retrieve const
>>> iterators from non-const container objects. Are there any plans to add
>>> these functions to stdcxx?
>> 
>> I assume you're referring to the Working Draft of the Standard for
>> Programming Language C++:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf
>> 
>> and the functions are those proposed in Walter Brown's Proposal
>> to Improve const_iterator Use from C++0X:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1674.pdf
> 
> Yes, the functions from Alternative 1 are the ones I was referring
> to. They will become especially handy when the "auto" feature is
> available in compilers. Does anyone know of a compiler that
> supports this use of auto?
> 
>> 
>> I have no immediate plans to implement these functions but we
>> certainly expect and plan to implement the new C++ standard by
>> the time it comes out.
>> 
>> If you would like to submit a patch with these functions or any
>> other feature that's expected to be in the next standard you
>> are most welcome to do so. Small extensions like this one might
>> be okay for trunk. Bigger features will probably be more
>> appropriate for a yet-to-be created branch as suggested in
>> STDCXX-299: https://issues.apache.org/jira/browse/STDCXX-299
> 
> I will work on a patch.
> 
> -- Mark
> 
>> 
>> Martin
>> 
>>> 
>>> -- Mark

[jira] Created: (STDCXX-355) new container member functions cbegin() and cend()

[Mark Brown (JIRA)]

new container member functions cbegin() and cend()
--

 Key: STDCXX-355
 URL: https://issues.apache.org/jira/browse/STDCXX-355
 Project: C++ Standard Library
  Issue Type: New Feature
  Components: 23. Containers
Affects Versions: 4.1.2, 4.1.3
Reporter: Mark Brown


This is a placeholder issue to implement the new container member functions 
cbegin(), cend(), crbegin() and crend() described in 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1674.pdf. See also 
this post in the archive:
http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200703.mbox/[EMAIL
 PROTECTED]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-353) [Cygwin] localedef errors: UCS value of symbolic character out of range

[Mark Brown (JIRA)]

[Cygwin] localedef errors: UCS value of symbolic character out of range
---

 Key: STDCXX-353
 URL: https://issues.apache.org/jira/browse/STDCXX-353
 Project: C++ Standard Library
  Issue Type: Bug
  Components: Locales
Affects Versions: 4.1.3
 Environment: Cygwin
Reporter: Mark Brown


On Cygwin, locale successfully builds all locales except zh_CN.GB18030 and 
zh_TW.EUC-TW:

$ nice make -C../bin locales -k
make: Entering directory `/home/mbrown/stdcxx-gcc-4.1.1-15s/bin'
./localedef -w -c -f /home/mbrown/stdcxx/etc/nls/charmaps/GB18030 -i 
/home/mbrown/stdcxx/etc/nls/src/zh_CN 
/home/mbrown/stdcxx-gcc-4.1.1-15s/nls/zh_CN.GB18030
Error 315: UCS value 66304 of symbolic character  out of range.
make: *** [zh_CN.GB18030] Error 4
./localedef -w -c -f /home/mbrown/stdcxx/etc/nls/charmaps/EUC-TW -i 
/home/mbrown/stdcxx/etc/nls/src/zh_TW 
/home/mbrown/stdcxx-gcc-4.1.1-15s/nls/zh_TW.EUC-TW
Error 315: UCS value 131083 of symbolic character  out of range.
make: *** [zh_TW.EUC-TW] Error 4
make: Target `locales' not remade because of errors.
make: Leaving directory `/home/mbrown/stdcxx-gcc-4.1.1-15s/bin'


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Cygwin 12d build issues

[Mark Brown]

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Thu, 08 Mar 2007 17:41:22 -0700
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: Cygwin 12d build issues
> 
> Mark or Farid, could one of you please open an issue for this?

Issue STDCXX-352 created: https://issues.apache.org/jira/browse/STDCXX-352

-- Mark

> 
> Thanks
> Martin
> 
> Farid Zaripov wrote:
>>> -Original Message-
>>> From: Martin Sebor [mailto:[EMAIL PROTECTED]
>>> Sent: Sunday, March 04, 2007 2:22 AM
>>> To: stdcxx-dev@incubator.apache.org
>>> Subject: Re: Cygwin 12d build issues
>>> 
>>> Mark Brown wrote:
>>>>> -Original Message-
>>>>> From: [EMAIL PROTECTED]
>>>>> Sent: Sat, 3 Mar 2007 11:33:26 -0800
>>>>> To: stdcxx-dev@incubator.apache.org
>>>>> Subject: Re: Cygwin 12d build issues
>>>>> 
>>>>> Thanks. I opened issue STDCXX-346 for the -fPIC warnings.
>>> I'll post a
>>>>> patch as soon as I'm done testing it.
>>>>> 
>>>>> What about the LIBC_EXCEPTIONS.exe problem with the popup window?
>>>> The other test that pops up this window is
>>> EXTERN_INLINE.exe. It says:
>>>> EXTERN_INLINE.exe has stopped working.
>>>> A problem caused the program to stop working  correctly.
>>>> Windows will close the program and notify you if a solution is
>>>> available.
>>> There shouldn't be any windows popping up when configuring,
>>> building, or using stdcxx. We have code that prevents the
>>> annoying Windows popups in tests that are expected to end
>>> abnormally (e.g., via an exception), for example,
>>> DYNAMIC_CAST.cpp, or NEW_THROWS.cpp, but I don't believe the
>>> two you mention are among them.
>>> 
>>> I suppose we could introduce a common header with the code
>>> and #include it from every test to prevent these popups even
>>> when they are not anticipated. It's something to think about.
>>> 
>>> In any case, please go ahead and open an issue for the problem.
>>> 
>>> I don't have a Cygwin environment handy to test it right now
>>> but Farid might. Farid, if you have installed Cygwin, could
>>> you do a build and see if you can reproduce it?
>> 
>>   I have just installed Cygwin. The problem is reproduced.
>> 
>>   We have the code that prevent theese popups, but only in
>> THREAD_SAFE_EXCEPTIONS.cpp:
>> 
>> #if defined (_WIN32)
>> // disable displaying the critical-error-handler
>> // and general-protection-fault message boxes
>> // windows.h included in thread.h
>> SetErrorMode (SEM_FAILCRITICALERRORS | SEM_NOGPFAULTERRORBOX);
>> #endif   // _WIN32
>> 
>> Farid.

RE: RFC: stdcxx 4.2 platforms

[Mark Brown]

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Thu, 08 Mar 2007 10:59:10 -0700
> To: stdcxx-dev@incubator.apache.org
> Subject: RFC: stdcxx 4.2 platforms
> 
> I think it's time for us to start planning the next stdcxx
> release. We have fixed a ton of bugs since 4.1.3 and 4.1.4
> and there have been a bunch of new platforms that we should
> certify (e.g., gcc 4.1 or MSVC 8 to name the most popular
> ones). I would also like us to clean up the Cygwin and Mac
> OS X ports that didn't work in previous releases. Are there
> any other new platforms we should provide support for?

I would find Cygwin test results helpful. It would also be helpful do 
semi-regular builds of some popular C++ software with stdcxx (like boost) and 
post the results.

-- Mark


FREE 3D MARINE AQUARIUM SCREENSAVER - Watch dolphins, sharks & orcas on your 
desktop!
Check it out at http://www.inbox.com/marineaquarium

[jira] Commented: (STDCXX-352) [Cygwin] Windows popups in optimized builds

[Mark Brown (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479885
 ] 

Mark Brown commented on STDCXX-352:
---

Also reproduced by Farid Zaripov: 
http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200703.mbox/[EMAIL
 PROTECTED]

> [Cygwin] Windows popups in optimized builds
> ---
>
> Key: STDCXX-352
> URL: https://issues.apache.org/jira/browse/STDCXX-352
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 4.1.3
> Environment: Cygwin, gcc
>Reporter: Mark Brown
>
> Originally posted here:
> http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200703.mbox/[EMAIL
>  PROTECTED]
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > Sent: Sat, 3 Mar 2007 11:33:26 -0800
> > To: stdcxx-dev@incubator.apache.org
> > Subject: Re: Cygwin 12d build issues
> > 
> > Thanks. I opened issue STDCXX-346 for the -fPIC warnings. I'll post
> > a patch as soon as I'm done testing it.
> > 
> > What about the LIBC_EXCEPTIONS.exe problem with the popup window?
> The other test that pops up this window is EXTERN_INLINE.exe. It says:
> EXTERN_INLINE.exe has stopped working.
> A problem caused the program to stop working  correctly.
> Windows will close the program and notify you if a solution is
> available.
> > 
> > -- Mark
> > 
> > 
> >> -Original Message-
> >> From: [EMAIL PROTECTED]
> >> Sent: Fri, 02 Mar 2007 10:13:47 -0700
> >> To: stdcxx-dev@incubator.apache.org
> >> Subject: Re: Cygwin 12d build issues
> >> 
> >> Mark Brown wrote:
> >>> Hi all,
> >>> 
> >>> Just for kicks I'm trying to build a 12d version of the library on
> >>> Cygwin. Things looks like they're going okay except for a couple of
> >>> errors that open up a message box on the screen telling me that a test
> >>> had a problem. The build stops at this point and waits for me to click
> >>> on a button before moving on to the next test. I don't remember the
> >>> first but the second one is for LIBC_EXCEPTIONS.exe. Is this normal?
> >>> 
> >>> I also see lots of messages like these:
> >>> 
> >>> make[2]: Entering directory `/home/mbrown/stdcxx-12d/lib'
> >>> generating dependencies for $(TOPDIR)/src/atomic.s
> >>> generating dependencies for $(TOPDIR)/src/wctype.cpp
> >>> /home/mbrown/stdcxx/src/wctype.cpp:0: warning: -fPIC ignored for target
> >>> (all code is position independent)
> >>> 
> >>> I'm guessing Cygwin might need the same conditional as the one for AIX
> >>> in gcc.config:
> >>> 
> >>> # IBM AIX code is always position independent
> >>> ifneq ($(OSNAME),AIX)
> >>> PICFLAGS= -fPIC
> >>> endif
> >> 
> >> Looks like it. If you could open an issue for this too,
> >> that would be great! A patch is also welcome :)
> >> 
> >> Thanks
> >> Martin
> >> 
> >>> 
> >>> -- Mark

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (STDCXX-352) [Cygwin] Windows popups in optimized builds

[Mark Brown (JIRA)]

[Cygwin] Windows popups in optimized builds
---

 Key: STDCXX-352
 URL: https://issues.apache.org/jira/browse/STDCXX-352
 Project: C++ Standard Library
  Issue Type: Bug
  Components: Build
Affects Versions: 4.1.3
 Environment: Cygwin, gcc
Reporter: Mark Brown


Originally posted here:

http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200703.mbox/[EMAIL
 PROTECTED]

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Sat, 3 Mar 2007 11:33:26 -0800
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: Cygwin 12d build issues
> 
> Thanks. I opened issue STDCXX-346 for the -fPIC warnings. I'll post
> a patch as soon as I'm done testing it.
> 
> What about the LIBC_EXCEPTIONS.exe problem with the popup window?

The other test that pops up this window is EXTERN_INLINE.exe. It says:

EXTERN_INLINE.exe has stopped working.
A problem caused the program to stop working  correctly.
Windows will close the program and notify you if a solution is
available.

> 
> -- Mark
> 
> 
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> Sent: Fri, 02 Mar 2007 10:13:47 -0700
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: Cygwin 12d build issues
>> 
>> Mark Brown wrote:
>>> Hi all,
>>> 
>>> Just for kicks I'm trying to build a 12d version of the library on
>>> Cygwin. Things looks like they're going okay except for a couple of
>>> errors that open up a message box on the screen telling me that a test
>>> had a problem. The build stops at this point and waits for me to click
>>> on a button before moving on to the next test. I don't remember the
>>> first but the second one is for LIBC_EXCEPTIONS.exe. Is this normal?
>>> 
>>> I also see lots of messages like these:
>>> 
>>> make[2]: Entering directory `/home/mbrown/stdcxx-12d/lib'
>>> generating dependencies for $(TOPDIR)/src/atomic.s
>>> generating dependencies for $(TOPDIR)/src/wctype.cpp
>>> /home/mbrown/stdcxx/src/wctype.cpp:0: warning: -fPIC ignored for target
>>> (all code is position independent)
>>> 
>>> I'm guessing Cygwin might need the same conditional as the one for AIX
>>> in gcc.config:
>>> 
>>> # IBM AIX code is always position independent
>>> ifneq ($(OSNAME),AIX)
>>> PICFLAGS= -fPIC
>>> endif
>> 
>> Looks like it. If you could open an issue for this too,
>> that would be great! A patch is also welcome :)
>> 
>> Thanks
>> Martin
>> 
>>> 
>>> -- Mark

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (STDCXX-338) [Cygwin] linker errors due to multiple definition of `std::exception::what()'

[Mark Brown (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479884
 ] 

Mark Brown commented on STDCXX-338:
---

If it helps, I also get the same error with the latest trunk and gcc 4.1.1:

gcc -c -I/home/mbrown/stdcxx/include/ansi -D_RWSTDDEBUG   -mthreads 
-D_RWSTD_USE_CONFIG -I/home/mbrown/stdcxx/include 
-I/home/mbrown/stdcxx-gcc-4.1.1-15s/include 
-I/home/mbrown/stdcxx/examples/include  -pedantic -nostdinc++ -g  -W -Wall 
-Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align   
t.cpp
gcc t.o -o t -mthreads -L/home/mbrown/stdcxx-gcc-4.1.1-15s/lib -lstd15s  
-lsupc++ -lcatgets -liconv -lm 
/usr/local/gcc-4.1.1/lib/gcc/i686-pc-cygwin/4.1.1/../../../libsupc++.a(eh_exception.o):
 In function `_ZNSt13bad_exceptionD2Ev':
/home/mbrown/gcc-4.1.1/libstdc++-v3/libsupc++/eh_exception.cc:38: multiple 
definition of `std::exception::what() const'
/home/mbrown/stdcxx-gcc-4.1.1-15s/lib/libstd15s.a(exception.o):/home/mbrown/stdcxx/src/exception.cpp:341:
 first defined here
collect2: ld returned 1 exit status
make: *** [t] Error 1


> [Cygwin] linker errors due to multiple definition of `std::exception::what()'
> -
>
> Key: STDCXX-338
> URL: https://issues.apache.org/jira/browse/STDCXX-338
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 4.1.3
>     Environment: Cygwin
>Reporter: Mark Brown
>
> When linking with stdcxx on Cygwin I get errors like:
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/libsupc++.a(eh_exception.o):(.text+0x80): 
> multiple definition of `std::exception::what() const' 
> The config.log file shows these errors for the EXCEPTION_WHAT test:
> gcc -c -pedantic -nostdinc++ -g  -Wall -W -Wcast-qual -Winline -Wshadow 
> -Wwrite-strings -Wno-long-long -Wcast-align -D_RWSTDDEBUG -D_RWSTD_USE_CONFIG 
> -I. /build
> /sebor/stdcxx-4.1.3/etc/config/src/EXCEPTION_WHAT.cpp
> In file included from 
> /home/mbrown/stdcxx-4.1.3/etc/config/src/EXCEPTION_WHAT.cpp:10:
> /home/mbrown/stdcxx-4.1.3/etc/config/src/BAD_ALLOC_ASSIGNMENT.cpp:83: 
> warning: `class std::exception' has virtual functions but non-virtual 
> destructor
> /home/mbrown/stdcxx-4.1.3/etc/config/src/BAD_ALLOC_ASSIGNMENT.cpp:333: 
> warning: unused parameter 'rhs'
> /home/mbrown/stdcxx-4.1.3/etc/config/src/BAD_ALLOC_ASSIGNMENT.cpp:388: 
> warning: unused parameter 'rhs'
> gcc EXCEPTION_WHAT.o   -lm -lsupc++ -o EXCEPTION_WHAT
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/libsupc++.a(eh_exception.o):(.text+0x0): 
> multiple definition of `std::exception::~exception()'
> EXCEPTION_WHAT.o:/home/mbrown/stdcxx-4.1.3/etc/config/src/BAD_ALLOC_ASSIGNMENT.cpp:(.text$_ZNSt9exceptionD2Ev[std::exception::~exception()]+0x0):
>  first defined here
> collect2: ld returned 1 exit status

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: new container member functions cbegin() and cend()

[Mark Brown]

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Fri, 09 Mar 2007 13:44:49 -0700
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: new container member functions cbegin() and cend()
> 
> Mark Brown wrote:
>> The next C++ standard adds a couple of new container member functions,
>> cbegin() and cend(), that will make it easier to retrieve const
>> iterators from non-const container objects. Are there any plans to add
>> these functions to stdcxx?
> 
> I assume you're referring to the Working Draft of the Standard for
> Programming Language C++:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2134.pdf
> 
> and the functions are those proposed in Walter Brown's Proposal
> to Improve const_iterator Use from C++0X:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1674.pdf

Yes, the functions from Alternative 1 are the ones I was referring
to. They will become especially handy when the "auto" feature is
available in compilers. Does anyone know of a compiler that
supports this use of auto?

> 
> I have no immediate plans to implement these functions but we
> certainly expect and plan to implement the new C++ standard by
> the time it comes out.
> 
> If you would like to submit a patch with these functions or any
> other feature that's expected to be in the next standard you
> are most welcome to do so. Small extensions like this one might
> be okay for trunk. Bigger features will probably be more
> appropriate for a yet-to-be created branch as suggested in
> STDCXX-299: https://issues.apache.org/jira/browse/STDCXX-299

I will work on a patch.

-- Mark

> 
> Martin
> 
>> 
>> -- Mark

RE: Cygwin libc_decl.sh script error

[Mark Brown]

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Fri, 9 Mar 2007 10:50:24 -0700
> To: stdcxx-dev@incubator.apache.org
> Subject: RE: Cygwin libc_decl.sh script error
> 
> Aha! That was the problem, difference between unix and windows line
> termination caused Cygwin to read in invalid character.  I had set
> Cygwin to read all files via binary.  I set Cygwin to read in DOS files
> and that solved the issue of script error.  I will continue to compile
> with gcc 4.1.1.

If you plan to work with the files under Cygwin downloading them in the
traditional UNIX format might make editing much easier. Otherwise some
editors might display control control characters for Windows newlines.
If I'm not mistaken, emacs likes to do that.

-- Mark

> 
> Yu (Scott) Zhong
> -Original Message-
> From: Farid Zaripov [mailto:[EMAIL PROTECTED]
> Sent: Friday, March 09, 2007 9:00 AM
> To: stdcxx-dev@incubator.apache.org
> Subject: RE: Cygwin libc_decl.sh script error
> 
>> -Original Message-
>> From: Martin Sebor [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, March 08, 2007 1:47 AM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: Cygwin libc_decl.sh script error
>> 
>> Scott Zhong wrote:
>>> Windows XP with Cygwin DLL 1.5.24-2
>>> 
>>> GNU GCC 4.1.1
>>> 
>>> 
>>> 
>>> checking if the compiler is sane   ok
>> (invoked with gcc)
>>> 
>>> checking if the linker is sane ok
>> (invoked with gcc)
>>> 
>>> checking system architecture   ILP32
>> little endian
>>> 
>>> : command not found/stdcxx/etc/config/src/libc_decl.sh: line 39:
>> 
>> What's on your line 39? The line is empty in both 4.1.3 and
>> trunk which makes me suspect that either your local copy is
>> corrupted or your Cygwin installation may be broken or incomplete.
> 
>   The problem is in that the bash requires the script files in unix
> format,
> but this files have the dos format on windows.
> 
>   All you need is convert *.sh files to unix format using dos2unix
> utility.
> 
>   Changes are commited thus:
> http://svn.apache.org/viewvc?view=rev&rev=516404
> 
> Farid.

new container member functions cbegin() and cend()

[Mark Brown]

The next C++ standard adds a couple of new container member functions, cbegin() 
and cend(), that will make it easier to retrieve const iterators from non-const 
container objects. Are there any plans to add these functions to stdcxx?

-- Mark

RE: Cygwin libc_decl.sh script error

[Mark Brown]

I have not tried gcc 4.1.1 on Cygwin yet but I successfully configured 
stdcxx/trunk with gcc 3.4.4. Aside from the problems I reported I also got it 
to build in at least one configuration. I have not seen the problem you pointed 
out.

-- Mark


> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Wed, 7 Mar 2007 16:11:56 -0700
> To: stdcxx-dev@incubator.apache.org
> Subject: Cygwin libc_decl.sh script error
> 
> Windows XP with Cygwin DLL 1.5.24-2
> 
> GNU GCC 4.1.1
> 
> 
> 
> checking if the compiler is sane   ok (invoked with gcc)
> 
> checking if the linker is sane ok (invoked with gcc)
> 
> checking system architecture   ILP32 little endian
> 
> : command not found/stdcxx/etc/config/src/libc_decl.sh: line 39:
> 
> : command not found/stdcxx/etc/config/src/libc_decl.sh: line 42:
> 
> : command not found/stdcxx/etc/config/src/libc_decl.sh: line 44:
> 
> /cygdrive/c/csports/stdcxx/etc/config/src/libc_decl.sh: line 103: syntax
> error near unexpected t
> 
> 'ken `do
> 
> 'cygdrive/c/csports/stdcxx/etc/config/src/libc_decl.sh: line 103: `for h
> in $hdrs ; do
> 
> 
> 
> checking for overloads of abs()ok
> 
> checking for atomic operations ok
> 
> checking for bad_alloc assignment operator  11 [sig]
> GLOBAL_BAD_EXCEPTION 3684 C:\cy
> 
> gwin\build\stdcxx\include\GLOBAL_BAD_EXCEPTION.exe: *** fatal error -
> called with threadlist_ix
> 
> -1
> 
> 
> 
> Yu (Scott) Zhong

compilation errors in 27.istream.fmat.arith.cpp

[Mark Brown]

Here's another test that throws an error at compile time. It looks like the 
compiler doesn't like the using N as the dimension of the array. I thought 
using variables as array dimensions was not allowed in C++?

gcc -pedantic -nostdinc++ -g  -W -Wall -Wcast-qual -Winline -Wshadow 
-Wwrite-strings -Wno-long-long -Wcast-align  -I/home/mbrown/stdcxx/include/ansi 
-D_RWSTDDEBUG-D_RWSTD_USE_CONFIG -I/home/mbrown/stdcxx/include 
-I/home/mbrown/stdcxx-gcc-3.4.4-11s/include -I/home/mbrown/stdcxx/../rwtest 
-I/home/mbrown/stdcxx/../rwtest/include -I/home/mbrown/stdcxx/tests/include  
-L/home/mbrown/stdcxx-gcc-3.4.4-11s/rwtest -lrwtest11s  
-L/home/mbrown/stdcxx-gcc-3.4.4-11s/lib -lstd11s   
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp 
/home/mbrown/stdcxx-gcc-3.4.4-11s/lib/libstd11s.a 
/home/mbrown/stdcxx-gcc-3.4.4-11s/rwtest/librwtest11s.a  -lsupc++ -lcatgets 
-liconv -lm -o 27.istream.fmat.arith
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp: In function 
`const std::locale make_locale(const CharT*, const LocaleData&)':
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp:67: error: ISO C++ 
forbids variable-size array `chars'
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp:68: error: ISO C++ 
forbids variable-size array `masks'
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp: In function 
`const std::locale make_locale(const CharT*, const LocaleData&) [with CharT = 
char]':
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp:179:   
instantiated from `const std::locale make_locale(const CharT*, const Traits*, 
const LocaleData&) [with CharT = char, Traits = std::char_traits]'
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp:309:   
instantiated from `void test_extractor(CharT*, Traits*, ArithmeticType*, const 
char*, const char*, const char*, int, const char*, const char*, size_t, const 
LocaleData&, int, int, int, int, int, int, int, ArithmeticType, ArithmeticType) 
[with CharT = char, Traits = std::char_traits, ArithmeticType = bool]'
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp:699:   
instantiated from `void test_bool(CharT*, Traits*, const char*, const char*) 
[with CharT = char, Traits = std::char_traits]'
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp:1245:   
instantiated from `void test_extractor(CharT*, Traits*, const char*, const 
char*) [with CharT = char, Traits = std::char_traits]'
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp:1310:   
instantiated from here
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp:67: error: ISO C++ 
forbids variable-size array
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp:67: error: storage 
size of `chars' isn't constant
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp:68: error: ISO C++ 
forbids variable-size array
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp:68: error: storage 
size of `masks' isn't constant
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp:71: error: ISO C++ 
forbids variable-size array
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp:71: error: ISO C++ 
forbids variable-size array
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp:75: error: ISO C++ 
forbids variable-size array
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp:75: error: ISO C++ 
forbids variable-size array
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp:76: error: ISO C++ 
forbids variable-size array
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp:76: error: ISO C++ 
forbids variable-size array
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp:83: error: ISO C++ 
forbids variable-size array
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp:83: error: ISO C++ 
forbids variable-size array
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp:88: error: ISO C++ 
forbids variable-size array
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp:88: error: ISO C++ 
forbids variable-size array
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp: In function 
`const std::locale make_locale(const CharT*, const LocaleData&) [with CharT = 
wchar_t]':
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp:179:   
instantiated from `const std::locale make_locale(const CharT*, const Traits*, 
const LocaleData&) [with CharT = wchar_t, Traits = std::char_traits]'
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp:309:   
instantiated from `void test_extractor(CharT*, Traits*, ArithmeticType*, const 
char*, const char*, const char*, int, const char*, const char*, size_t, const 
LocaleData&, int, int, int, int, int, int, int, ArithmeticType, ArithmeticType) 
[with CharT = wchar_t, Traits = std::char_traits, ArithmeticType = 
bool]'
/home/mbrown/stdcxx/tests/iostream/27.istream.fmat.arith.cpp:699:   
instantiated from `void test_bool(CharT*, Traits*, const char*, const char*) 
[with Ch

compilation error in 0.alloc.cpp

[Mark Brown]

I'm trying to compile the tests on Cywgin and I'm getting some errors. Here's 
the first one. I tried to see if it was something obvious that I could easily 
fix myself but the code in both cases is a macro defined to yet another macro 
that expands to either setjmp or sigsetjmp if that's a macro too. Too many 
macros... Hopefully someone better at macro hacking than me will be able to 
figure what's going on.

gcc -c -I/home/mbrown/stdcxx/include/ansi -D_RWSTDDEBUG-D_RWSTD_USE_CONFIG 
-I/home/mbrown/stdcxx/include -I/home/mbrown/stdcxx-gcc-3.4.4-11s/include 
-I/home/mbrown/stdcxx/../rwtest -I/home/mbrown/stdcxx/../rwtest/include 
-I/home/mbrown/stdcxx/tests/include  -pedantic -nostdinc++ -g  -W -Wall 
-Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align   
/home/mbrown/stdcxx/tests/self/0.alloc.cpp
/home/mbrown/stdcxx/tests/self/0.alloc.cpp: In function `void test(const 
TestCase&)':
/home/mbrown/stdcxx/tests/self/0.alloc.cpp:93: error: cannot convert `int 
(*)[52]' to `int (*)[54]' in initialization
/home/mbrown/stdcxx/tests/self/0.alloc.cpp:102: error: cannot convert `int 
(*)[52]' to `int (*)[54]' in initialization
make: *** [0.alloc.o] Error 1

-- Mark


FREE ONLINE PHOTOSHARING - Share your photos online with your friends and 
family!
Visit http://www.inbox.com/photosharing to find out more!

typo in alloc.cpp

[Mark Brown]

Hi,

There appears to be a little typo in the source file alloc.cpp as pointed out 
by the gcc compilation error on Cygwin. The patch below fixes it.

gcc -c -I/home/mbrown/stdcxx/include/ansi -D_RWSTDDEBUG-D_RWSTD_USE_CONFIG 
-I/home/mbrown/stdcxx/include -I/home/mbrown/stdcxx-gcc-3.4.4-11s/include 
-I/home/mbrown/stdcxx/../rwtest -I/home/mbrown/stdcxx/tests/include  -pedantic 
-nostdinc++ -g  -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings 
-Wno-long-long -Wcast-align   /home/mbrown/stdcxx/tests/src/alloc.cpp
/home/mbrown/stdcxx/tests/src/alloc.cpp:97: error: comma at end of enumerator 
list
/home/mbrown/stdcxx/tests/src/alloc.cpp: In function `DWORD 
_rw_translate_prot(int)':
/home/mbrown/stdcxx/tests/src/alloc.cpp:120: warning: comparison between signed 
and unsigned integer expressions
make[1]: *** [alloc.o] Error 1
make[1]: Leaving directory `/home/mbrown/stdcxx-gcc-3.4.4-11s/rwtest'
make: *** [/home/mbrown/stdcxx-gcc-3.4.4-11s/rwtest/librwtest11s.a] Error 2


Index: /home/mbrown/stdcxx/tests/src/alloc.cpp
===
--- /home/mbrown/stdcxx/tests/src/alloc.cpp (revision 514239)
+++ /home/mbrown/stdcxx/tests/src/alloc.cpp (working copy)
@@ -93,7 +93,7 @@
 PROT_READ  = 1 << 0,
 PROT_WRITE = 1 << 1,
 PROT_RDWR  = PROT_READ | PROT_WRITE,
-PROT_EXEC  = 1 << 2,
+PROT_EXEC  = 1 << 2
 };
 
 #define MAP_PRIVATE   0

-- Mark

[PATCH] for STCXX-346 - [Cygwin] gcc -fPIC warnings

[Mark Brown]

Here's a patch for the -fPIC warnings on Cygwin (issue STCXX-346). I got a 
little crafty with the conditional and used findstring instead of two ifs. I 
hope that's okay. I also took the liberty to add a "-*- Makefile -*-" tag to 
the top of the file to enable emacs syntax highlighting.

-- Mark

Index: /home/mbrown/stdcxx/etc/config/gcc.config
===
--- /home/mbrown/stdcxx/etc/config/gcc.config   (revision 513621)
+++ /home/mbrown/stdcxx/etc/config/gcc.config   (working copy)
@@ -1,3 +1,4 @@
+#  -*- Makefile -*-
 #
 # $Id$
 #
@@ -48,9 +49,10 @@
 
 DEPENDFLAGS = -M
 
-# IBM AIX code is always position independent
-ifneq ($(OSNAME),AIX)
-PICFLAGS= -fPIC
+# avoid adding -FPIC on IBM AIX and Cygwin where
+# gcc generated code is always position independent
+ifeq (,$findstring |$(OSNAME)|,|AIX|CYGWIN|)
+PICFLAGS = -fPIC
 endif
 
 ifeq ($(OSNAME),SunOS)


ONE-CLICK WEBMAIL ACCESS - Easily monitor & access your email accounts!
Visit http://www.inbox.com/notifier and check it out!

[jira] Commented: (STDCXX-337) [Cygwin] unsats on _libiconv, _catgets

[Mark Brown (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477681
 ] 

Mark Brown commented on STDCXX-337:
---

I'm not sure how it happened but there's a typo in the patch I suggested above 
(my local copy is okay). The flag should have been -lcatgets, not -catgets. I'm 
sorry for the trouble.

> [Cygwin] unsats on _libiconv, _catgets
> --
>
> Key: STDCXX-337
> URL: https://issues.apache.org/jira/browse/STDCXX-337
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: Build
>Affects Versions: 4.1.3
>     Environment: Cygwin
>Reporter: Mark Brown
>
> I tried to build the library on Cygwin but I'm getting linker errors for the 
> localedef utility. I have the iconv library installed (in /usr/lib) but make 
> isn't linking with it. I also get linker errors for _catopen, _catgets, and 
> _catclose. I searched under /usr/lib to see what library defines these 
> symbols and it's libcatgets.a. Should the makefile be linking with it?
> gcc localedef.o aliases.o charmap.o codecvt.o collate.o ctype.o def.o 
> diagnostic.o messages.o monetary.o numeric.o path.o time.o scanner.o -o 
> localedef  -L/home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s/lib -lstd11s  -lsupc++ 
> -lm 
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/libsupc++.a(eh_exception.o):(.text+0x80): 
> multiple definition of `std::exception::what() const'
> /home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s/lib/libstd11s.a(exception.o):/home/mbrown/stdcxx-4.1.3/src/exception.cpp:334:
>  first defined here
> charmap.o: In function `_ZNSt4pairIKwSsEC1ERKS1_':
> /home/mbrown/stdcxx-4.1.3/include/rw/_specialized.h:(.text+0x4c0): undefined 
> reference to `_libiconv_open'
> charmap.o: In function `_ZNK7Charmap15convert_to_utf8EPKcjPcj':
> /home/mbrown/stdcxx-4.1.3/util/charmap.cpp:346: undefined reference to 
> `_libiconv'
> /home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s/lib/libstd11s.a(messages.o): In 
> function `_ZN4__rw13__rw_cat_openERKSsRKSt6locale':
> /home/mbrown/stdcxx-4.1.3/src/messages.cpp:205: undefined reference to 
> `_catopen'
> /home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s/lib/libstd11s.a(messages.o): In 
> function `_ZN4__rw16__rw_get_messageEiii':
> /home/mbrown/stdcxx-4.1.3/src/messages.cpp:235: undefined reference to 
> `_catgets'
> /home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s/lib/libstd11s.a(messages.o): In 
> function `_ZN4__rw14__rw_cat_closeEi':
> /home/mbrown/stdcxx-4.1.3/src/messages.cpp:277: undefined reference to 
> `_catclose'
> collect2: ld returned 1 exit status
> make[2]: *** [localedef] Error 1
> make[2]: Leaving directory `/home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s/bin'
> make[1]: *** [util] Error 2
> make[1]: Leaving directory `/home/mbrown/stdcxx-4.1.3-gcc-3.4.4-11s'
> make: *** [libstd] Error 2

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Cygwin 12d build issues

[Mark Brown]

> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Sat, 3 Mar 2007 11:33:26 -0800
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: Cygwin 12d build issues
> 
> Thanks. I opened issue STDCXX-346 for the -fPIC warnings. I'll post
> a patch as soon as I'm done testing it.
> 
> What about the LIBC_EXCEPTIONS.exe problem with the popup window?

The other test that pops up this window is EXTERN_INLINE.exe. It says:

EXTERN_INLINE.exe has stopped working.
A problem caused the program to stop working  correctly.
Windows will close the program and notify you if a solution is
available.

> 
> -- Mark
> 
> 
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> Sent: Fri, 02 Mar 2007 10:13:47 -0700
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: Cygwin 12d build issues
>> 
>> Mark Brown wrote:
>>> Hi all,
>>> 
>>> Just for kicks I'm trying to build a 12d version of the library on
>>> Cygwin. Things looks like they're going okay except for a couple of
>>> errors that open up a message box on the screen telling me that a test
>>> had a problem. The build stops at this point and waits for me to click
>>> on a button before moving on to the next test. I don't remember the
>>> first but the second one is for LIBC_EXCEPTIONS.exe. Is this normal?
>>> 
>>> I also see lots of messages like these:
>>> 
>>> make[2]: Entering directory `/home/mbrown/stdcxx-12d/lib'
>>> generating dependencies for $(TOPDIR)/src/atomic.s
>>> generating dependencies for $(TOPDIR)/src/wctype.cpp
>>> /home/mbrown/stdcxx/src/wctype.cpp:0: warning: -fPIC ignored for target
>>> (all code is position independent)
>>> 
>>> I'm guessing Cygwin might need the same conditional as the one for AIX
>>> in gcc.config:
>>> 
>>> # IBM AIX code is always position independent
>>> ifneq ($(OSNAME),AIX)
>>> PICFLAGS= -fPIC
>>> endif
>> 
>> Looks like it. If you could open an issue for this too,
>> that would be great! A patch is also welcome :)
>> 
>> Thanks
>> Martin
>> 
>>> 
>>> -- Mark


ONE-CLICK WEBMAIL ACCESS - Easily monitor & access your email accounts!
Visit http://www.inbox.com/notifier and check it out!

Re: Cygwin 12d build issues

[Mark Brown]

Thanks. I opened issue STDCXX-346 for the -fPIC warnings. I'll post
a patch as soon as I'm done testing it.

What about the LIBC_EXCEPTIONS.exe problem with the popup window?

-- Mark


> -Original Message-
> From: [EMAIL PROTECTED]
> Sent: Fri, 02 Mar 2007 10:13:47 -0700
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: Cygwin 12d build issues
> 
> Mark Brown wrote:
>> Hi all,
>> 
>> Just for kicks I'm trying to build a 12d version of the library on
>> Cygwin. Things looks like they're going okay except for a couple of
>> errors that open up a message box on the screen telling me that a test
>> had a problem. The build stops at this point and waits for me to click
>> on a button before moving on to the next test. I don't remember the
>> first but the second one is for LIBC_EXCEPTIONS.exe. Is this normal?
>> 
>> I also see lots of messages like these:
>> 
>> make[2]: Entering directory `/home/mbrown/stdcxx-12d/lib'
>> generating dependencies for $(TOPDIR)/src/atomic.s
>> generating dependencies for $(TOPDIR)/src/wctype.cpp
>> /home/mbrown/stdcxx/src/wctype.cpp:0: warning: -fPIC ignored for target
>> (all code is position independent)
>> 
>> I'm guessing Cygwin might need the same conditional as the one for AIX
>> in gcc.config:
>> 
>> # IBM AIX code is always position independent
>> ifneq ($(OSNAME),AIX)
>> PICFLAGS= -fPIC
>> endif
> 
> Looks like it. If you could open an issue for this too,
> that would be great! A patch is also welcome :)
> 
> Thanks
> Martin
> 
>> 
>> -- Mark

[jira] Created: (STDCXX-346) [Cygwin] gcc -fPIC warnings

[Mark Brown (JIRA)]

[Cygwin] gcc -fPIC warnings
---

 Key: STDCXX-346
 URL: https://issues.apache.org/jira/browse/STDCXX-346
 Project: C++ Standard Library
  Issue Type: Bug
  Components: Build
Affects Versions: 4.1.3
 Environment: gcc 3.4.4 on Cygwin
Reporter: Mark Brown


gcc shared library build on Cygwin spits out a warning message about the -fPIC 
flag on the command line for every .cpp file:

make[2]: Entering directory `/home/mbrown/stdcxx-12d/lib'
generating dependencies for $(TOPDIR)/src/atomic.s
generating dependencies for $(TOPDIR)/src/wctype.cpp
/home/mbrown/stdcxx/src/wctype.cpp:0: warning: -fPIC ignored for target (all 
code is position independent)

Removing the -fPIC gets rid of the warnings so I'm guessing Cygwin might need 
the same conditional as the one for AIX in gcc.config:

# IBM AIX code is always position independent
ifneq ($(OSNAME),AIX)
PICFLAGS= -fPIC
endif

Here's the archived post where this problem was first raised:
http://mail-archives.apache.org/mod_mbox/incubator-stdcxx-dev/200703.mbox/[EMAIL
 PROTECTED]

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Cygwin cannot find -lstd12d

[Mark Brown]

Hi again,

Sorry about all the emails tonight. I'm sending them out as I run into things. 
Hopefully they'll be useful. After the library built all examples are now 
getting the same error. Looks like the Cygwin linker can't find the library 
even though it's there (I checked :)

$ make
gcc -c -I/home/mbrown/stdcxx/include/ansi   -mthreads -D_RWSTD_USE_CONFIG 
-I/home/mbrown/stdcxx/include -I/home/mbrown/stdcxx-12d/include 
-I/home/mbrown/stdcxx/examples/include  -pedantic -nostdinc++ -O2  -W -Wall 
-Wcast-qual -Winline -Wshadow -Wwrite-strings -Wno-long-long -Wcast-align   
/home/mbrown/stdcxx/examples/manual/accumulate.cpp

(...lots of warnings about failed inlining...)

gcc accumulate.o -o accumulate -mthreads -L/home/mbrown/stdcxx-12d/lib -lstd12d 
 -lsupc++ -lcatgets -liconv -lm 
/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/bin/ld: cannot 
find -lstd12d
collect2: ld returned 1 exit status
make: *** [accumulate] Error 1


-- Mark

some Cygwin 12d warnings

[Mark Brown]

Okay, after I took out the -fPIC flag to get rid of the pesky warnings the 
library build went fine with just a couple of warnings. What's the policy when 
it comes to warnings? Are some warnings expected or are builds supposed to be 
completely clean?

gcc -c -I/home/mbrown/stdcxx/include/ansi   -mthreads -D_RWSTD_USE_CONFIG 
-I/home/mbrown/stdcxx/include -I/home/mbrown/stdcxx-12d/include  -pedantic 
-nostdinc++ -O2  -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings 
-Wno-long-long -Wcast-align/home/mbrown/stdcxx/src/collate.cpp
/home/mbrown/stdcxx/src/collate.cpp: In member function `virtual 
std::basic_string, std::allocator > 
std::collate_byname::do_transform(const char*, const char*) const':
/home/mbrown/stdcxx/src/collate.cpp:484: warning: 'pbuf' might be used 
uninitialized in this function
/home/mbrown/stdcxx/src/collate.cpp: In member function `virtual 
std::basic_string, std::allocator > 
std::collate_byname::do_transform(const wchar_t*, const wchar_t*) 
const':
/home/mbrown/stdcxx/src/collate.cpp:687: warning: 'pbuf' might be used 
uninitialized in this function

And also:

gcc -c -I/home/mbrown/stdcxx/include/ansi   -mthreads -D_RWSTD_USE_CONFIG 
-I/home/mbrown/stdcxx/include -I/home/mbrown/stdcxx-12d/include  -pedantic 
-nostdinc++ -O2  -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings 
-Wno-long-long -Wcast-align/home/mbrown/stdcxx/src/iostore.cpp
/home/mbrown/stdcxx/src/iostore.cpp: In member function `void 
std::ios_base::_C_copyfmt(const std::ios_base&, void*, const void*, unsigned 
int)':
/home/mbrown/stdcxx/src/iostore.cpp:187: warning: 'except' might be used 
uninitialized in this function


-- Mark

Cygwin 12d build issues

[Mark Brown]

Hi all,

Just for kicks I'm trying to build a 12d version of the library on Cygwin. 
Things looks like they're going okay except for a couple of errors that open up 
a message box on the screen telling me that a test had a problem. The build 
stops at this point and waits for me to click on a button before moving on to 
the next test. I don't remember the first but the second one is for 
LIBC_EXCEPTIONS.exe. Is this normal?

I also see lots of messages like these:

make[2]: Entering directory `/home/mbrown/stdcxx-12d/lib'
generating dependencies for $(TOPDIR)/src/atomic.s
generating dependencies for $(TOPDIR)/src/wctype.cpp
/home/mbrown/stdcxx/src/wctype.cpp:0: warning: -fPIC ignored for target (all 
code is position independent)

I'm guessing Cygwin might need the same conditional as the one for AIX in 
gcc.config:

# IBM AIX code is always position independent
ifneq ($(OSNAME),AIX)
PICFLAGS= -fPIC
endif

-- Mark

[jira] Commented: (STDCXX-24) [Cygwin] collate.cpp needs wcsnxfrm

[Mark Brown (JIRA)]

[ 
https://issues.apache.org/jira/browse/STDCXX-24?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12477188
 ] 

Mark Brown commented on STDCXX-24:
--

I can compile the latest library on Cygwin without any errors from collate.cpp.

> [Cygwin] collate.cpp needs wcsnxfrm
> ---
>
> Key: STDCXX-24
> URL: https://issues.apache.org/jira/browse/STDCXX-24
> Project: C++ Standard Library
>  Issue Type: Bug
>  Components: 22. Localization
>Affects Versions: 4.1.2
> Environment: Cygwin
>Reporter: Lance Diduck
> Fix For: 4.2
>
>
> Martin Sebor paraphrased:
> Cygwin really doesn't define wcsnxfrm() (i.e.,  both
> _RWSTD_NO_WCSXFRM and _RWSTD_NO_WCSXFRM_IN_LIBC are #defined) 
> we should probably implement our own transformation. 
> Looking at
> collate.cpp, though, I don't see a check for _RWSTD_NO_WCSXFRM_IN_LIBC,
> just for the former (which only determines whether function is declared;
> the latter tells us if it's also not defined).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.