Sv: Details on some bugs in PenguinFile

["Bjarke Hammersholt Roune" <asmild@post6.tele.dk>]

>>The value yielded by _PP_FUNCTION_NAME must NOT be const. __LINE__ and
>>
>In contrary - it *should* be const (to indicate that it is not modified by
>ppFatalError ())
>The problem is rather that _pp_db_func_loc () is of type char ** (instead
>of const char **)
>
Sorry... That is obviously so...

>>__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...

>>**** 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++)
>>-
>>Some compilers does not have a problem with this. However, some do, and
mine
>>is one of them. In cases like this, declare the variable i outside the for
>>
>Ugh. Poor guy.
>

At the time MS VC++ was released, this was the way it was supposed to
behave.

>>statement and just initialize it there if you are going to use it more
than
>>once withind the same scope. That should work for everyone.
>
>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.

>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? ;)

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.