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 ;-). Any change StrDup is a macro so we can just undef in in Windows4Root.h? -- 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