Re: [ROOT] Re: StrDup

From: Fons Rademakers (Fons.Rademakers@cern.ch)
Date: Wed Nov 21 2001 - 05:42:05 MET


Hi Valery,

   thanks, I agree completely. Just adding StrDup to the Win4Root.h to
get rid of the M$ define should be fine.


-- Fons



On Tue, Nov 20, 2001 at 12:36:04PM -0500, Valeri Fine 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.
> 
>    Nooooo !!!!  I MUST disagree.  This  way we (ROOT users) will be forced 
>    to do the same across  OUR codes with NO solid reason. Just because one ROOT 
>    guy  doesn't want to delete a line of his code.
>    One can not solve the problem with
> 
>       #define StrDup R_StrDup
> 
>   since MS include file does exactly the same
> 
>       #define StrDup StrDupA
> 
>   EXTREMELY expansive exercise even  ROOT is free 
> 
>    If he can not remove that line I would advice him to add one extra line:
> 
>    #include <shlwapi.h>
>    #undef StrDup
> 
> That must solve his local problem and introduce no new one for the rest ROOT
> community.
> 
> 
> 
>                    Best regards, Valeri
> 
> 
> 
> > 
> > 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