stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance Diduck" <lancedid...@nyc.rr.com>
Subject RE: svn co
Date Sun, 28 Aug 2005 21:05:56 GMT
I'll let you know how the Cygwin client turns out, its still downloading.
I'll still have to work around the case issues. (The solution I did come up
with is to do a svn list, copy the files names, exclude the problem files,
and then do svn cp on each file. Subversion doesn't like this, and requires
doing each directory by hand ( no recursion,) and everything stays locked.
Subversion solves the issue by asserting that they are a case -insensitive
repository. 

The macro clash issue is with yvals.h, and by intent everything was mixed
together, just seeing what happened. The only real change I know of in this
Dinkumware is that the non-standard constructs (like hash_set) were moved
out of namespace std; 
But I run across "dueling STL implementation" problems quite often in fact,
so much so that I don't allow any STL containers, streams and such in the
public interfaces of the code my teams writes. Apart from stream
initialization problems, this was the first time I had trouble making two
STLs coexist. 

<< Possibly, although I personally am not a fan of the security TR.>>
MSVC doesn't tell you what to replace the offending functions with, at least
not in the compiler warnings. They'll probably advise "replace with .NET" if
asked. There are secure OS system calls for things like string formatting
that I use when I do windows stuff (things like IE ActiveX controls don't
have to be portable to unix, and adding in seemingly innocuous standard C
lib calls will kill you during deployment.) These have been around for ages.


OK looks like my Cygwin install is trying to make an insecure connection to
the internet. I'll keep you posted.

BTW I tried to subscribe to the mailing list and got this unusual error

   ----- The following addresses had permanent fatal errors -----
<stdcxx-dev-subscribe@apache.incubator.com>
    (reason: 553 sorry, that domain isn't in my list of allowed rcpthosts
(#5.7.1))

I'll try again later. 

-----Original Message-----
From: Martin Sebor [mailto:sebor@roguewave.com] 
Sent: Sunday, August 28, 2005 4:12 PM
To: Lance Diduck
Cc: stdcxx-dev@incubator.apache.org
Subject: Re: svn co

Lance Diduck wrote:
> Yes -- I am trying Cygwin now. It takes forever to download and install,
and
> I'll have to find out if there is a Subversion client for Cygwin.

You could use the Windows client. The CygWin client, if there is one,
will probably not help you work around the case insensitivity issue.

[...]
> 
> <<changes to the library>> 
> I'll just get a dev environment working first :) But one thing to look at
is
> that _STD is a macro that Dinkumware tries to own in their latest release
as
> well. They #undef it everytime they see it. ( I ran a few of the stdcxx
file
> through MSVC8, that was a show stopper. )

They've always done that (AFAIK, in yvals.h). The clash indicates
that you are somehow mixing two different implementations of the
library. That should never happen. One possible reason is that
more of the VS 8 headers #include <yvals.h> now than in VS 7.1.
Do you know which public VS 8 header is causing the collision?

> 
> 
> << You mean they deprecated standard C string functions such as strcpy >>
> Yes. It shows up as compiler warnings now, but one could surmise that
> corporate IT departments will soon start auditing for this sort of thing.
My
> employer already does this.

Possibly, although I personally am not a fan of the security TR.
It's a tool that's might potentially be useful as a quick a dirty
hack around bugs in legacy software, but not one to be applied in
the development of new code.

For some interesting comments from the experts see the Austin Group
Review of the document here:
http://www.opengroup.org/austin/jan2005/uploads/40/7171/n1118.htm

Martin



Mime
View raw message