> Hi,
>
> first off strdup is not a posix call so for some systems we have
> to provide our own implementation (like for strcasecmp). StrDup()
> however, is different in that it allocates memory using new[]
> and that therefore its returned strings have to be deleted using
> delete []. Of course we made the mistake of using the global namespace
> which, as we all know, belongs to M$ and so now we have to make a backward
> incompatible change to either R__StrDup or to TString::StrDup() (static
> method in TString class). Thinking about it, what do we do do if M$ decides
> to use classes with the name T<something> change all our classes to
> R__TString? Better move to namespaces soon to avoid that from happening ;-).
Dear Fons,
The bottom line:
I see NO reason to make ROOT backward incompatible even to provide an extra proof
that Microsoft is an evil.
I 'd like to remind:
1. We are speaking about of C rather C++ language. The former has neither
"namespace" nor "classes what so ever.
2. In this particular case we are speaking about a "stand-alone" library and StrDup
in question is neither part of Micorosft Visual C run-time library nor part of Win32 API
It is a part DLL of "Microsoft Internet Explorer v.4.0" that we may not care about.
3. Any user is free to chose the technique he/she thinks is appropriated. This have not to entail
ROOT package should be changed to make that single user happy and force others
to change their codes I understand you hate to behave Microsoft-like to do what ever you
can to preserve backward compatibility.
I think this particular case needs no response from the ROOT team.
So I see NO reason to make ROOT backward incompatible even to provide an extra proof
that Microsoft is an evil.
Just a good advice to remove #include "shwapi.h" from the user code is sufficient to close
this thread.
> Any change StrDup is a macro so we can just undef in in Windows4Root.h?
One can do that It does no harm. However it may not help that user anyway because
StrDup macro comes from non-standard include file that ROOT packages itself doesn't use.
With my best regards, Valeri
> -- Fons
>
>
> On Tue, Nov 20, 2001 at 05:07:52PM +0000, Rene Brun wrote:
> > Hi Valery,
> >
> > Thanks for this nice explanation. Microsoft had recently the same idea
> > than us 7 years ago ::)
> >
> > If nobody objects, I will rename this function StrDup to R__StrDup.
> >
> > Rene Brun
> >
> > Valeri Fine wrote:
> > >
> > > Hi, Brandos I ewould appreciate you probide Sbj line with your messages.
> > > I used to delete right away any message with no "Subj"
> > >
> > > Coming back to Rene's answer:
> > >
> > > > The functions like Strdup were implemented in the early days of Root
> > > > under Windows to circumvent deficiencies in the Windows implementation
> > > > of the standard Posix functions (well strdup is not posix), strchr, strcpy, etc.
> > > > We found that the Windows implementation crashes if you pass a null pointer
> > > > eg to strchr.
> > > > The ROOT code is now protected everywhere against calls to these functions
> > > > with null pointers.
> > > > Functions like Strdup could be removed from existing code and we do not use it
> > > > in the new code.
> > > >
> > > > However, I do not understand how you can get a duplication with Strdup.
> > > > This function is not defined in the MS libs.
> > >
> > > It is not correct. MS has introduced this function recently,
> > > Very likely they had had the same reason ROOT team had:
> > >
> > > 1. There is no standard for strdup
> > >
> > > 2. the behaviour of str<bla> functions provided with zero pointer is not defined
> > > and causes the program crash (not under Windows only. It is still true for other
> > > (UNIX) platforms also.
> > >
> > > However I have to mention MS defines his StrDup function with
> > > "#include <shlwapi.h>"
> > > If one could avoid this include one may have avoided the name clash.
> > >
> > > (See attachment)
> > >
> > > Best regards, Valeri
> > > >
> > > > Rene Brun
> > > >
> > > > Brandon Kohn wrote:
> > > > >
> > > > > Part 1.1 Type: Plain Text (text/plain)
> > > > > Encoding: quoted-printable
> > > > Hello all,
> > > >
> > > > I've been mucking around with Root and win32 stuff for a while now, and I've
> > > > found some curiosities that I would like answered. For one, it seems that root
> > > > redefines some functions that exist in standard libraries (ansi, unix, and
> > > > win32). For instance, the function StrDup in TString. I get name conflicts
> > > > when I try to compile root objects (TH1 for instance) with some codes that
> > > > already include the function from the standard lib. A cursory inspection of the
> > > > code StrDup shows that it simply new's a char array, strcpy's the string and
> > > > returns the ptr to the new array. Is this different then what the standard lib
> > > > does?
> > > >
> > > > If not, can it be removed from Root?
> > > >
> > > > Brandon Kohn
> > > > +377 97 97 41 50 ext. 306 (Work)
> > > > +377 97 77 86 71 (Home)
> > > > Monaco
> > > >
> > >
> > > --------------------------------------------------------------------------------
> > >
> > > Name: Text1.tmp
> > > Text1.tmp Type: unspecified type (application/octet-stream)
> > > Encoding: 7bit
>
> --
> Org: CERN, European Laboratory for Particle Physics.
> Mail: 1211 Geneve 23, Switzerland
> E-Mail: Fons.Rademakers@cern.ch Phone: +41 22 7679248
> WWW: http://root.cern.ch/~rdm/ Fax: +41 22 7679480
>
This archive was generated by hypermail 2b29 : Tue Jan 01 2002 - 17:51:09 MET