[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Sv: Details on some bugs in PenguinFile



Bjarke Hammersholt Roune wrote:

>>>__FILE__ is not const either. Actually, this code:
>>>
>>???????
>>__FILE__ is evaluated by the preprocessor into a string constant. Ever
>>tried to change your current source file name at runtime?
>>
>>Then your compiler really has a problem.
>>>So, p1 and p2 points to different storage, and that's why the __FILE__ can
>>>yield non-const values safely.
>>Then the preprocessor would need to change
>>-----
>>char *p1 = __FILE__;
>>-----
>>to something like this:
>>-----
>>#include <string.h>
>>char *p1 = (char *) malloc (strlen ("thisfilesname"));
>>strcpy (p1, "thisfilesname");
>>-----
>>
>>
>>Sorry, that's just too crazy (on the other hand - it would explain the
>>memory leaks in MS products ... ;)
>>
>No it wouldn't. This would do it:
>
>char[] __FILE__ = "c:\myfile.cpp"
>
>
>and that's exactly the way it behaves. You seem to suggest this is not
>standard behavior. I don't know...

Well, when some program is compiled, the names of its source files should
be pretty constant, right?

>>>**** double-initialization ****
>>>'i' : redefinition; multiple initialization
>>>
>>>ppf_GlobalData.cc, line 67, ppf_TGlobalData::ppf_TGlobalData()
>>>for (int i=0 ; i < ppfAM_numvals ; i++)
>>>
>>>ppf_GlobalData.cpp, line 93, ppf_TGlobalData::~ppf_TGlobalData()
>>>for (int i=0 ; i < ppfAM_numvals ; i++)
>>
>>STOP - wait a minute. i is *once* initialized in
>>ppf_TGlobalData::ppf_TGlobalData (i.e. the CONstructor) and *once* in
>>ppf_TGlobalData::~ppf_TGlobalData  (i.e. the DEstructor) - that's two
>>different methods!!!!
>>
>>Do you really want to say that MSVC has a problem with that?????
>>
>Yes I do; there's an reinitialising error in EACH method: it' shappends
>TWICE. TWO times.

Ah, oh. Then that actually changed. The current ppf_GlobalData
constructor/destructor only initialize i once.

>>ppf_GlobalData.cc has been 90% rewritten in the current version. Can you
>>recheck it?
>>
>Well, I'll have to to get it to compile, won't I? ;)

It's in cvs.

>Btw, I'll be traveling away to a very hot place I very much suspect does not
>have internet access nor computers for 2 weeks on tuesday.

Ok.


	Christian
--

Drive A: not responding...Formatting C: instead