SV: Phew...

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

> >Btw, is it really nessecary to iterator over *entries* ? Isn't
> it sufficient
>
> Yup.
>
Yup to what? Yup to that it is nessecary, or yup to that it is sufficient
not to?

> >__ppInternalError
> >char const * const  _ppNoFuncNameMsg
> >__pp_db_func_loc
> >__pp_db_lineno_loc
> >__ppWarning
> >__ppFatalError
> >__ppDebug
> >char * __cdecl pp::internal::Strdup(char const *)
> >char * __cdecl pp::internal::Strndup(char const *,unsigned int)
>
> All implemented in src/ppUtils.cpp
> Did you compile and link that?
>
No. You placed it in src/, so I missed it. Shouldn't that be with the global
headers?

It works now.

There's a bug in Strndup(), though:

	try {
		char *Dest = new char [Length + 1];
	} catch (std::bad_alloc) {
		ppWarning ("Out of Memory");
		return 0;
	}

	/* Safety check for implementations that do not throw bad_alloc */
	if (Dest == 0)
	{
		ppWarning ("Out of Memory");
		return 0;
	}

Dest is only scoped to the try block, so it can't be used in the if check.
Furthermore, it should std::bad_alloc, and <new> should be included.

> >int __cdecl pp::internal::CopyToPlain(class pp::internal::URLInfo const
> >&,class pp::internal::URLInfo const &,struct ppfDirEntry &)
>
> Now that's weird... I'll look into that.
>
Here's the definition of CopyToPlain in Read.h:

int CopyToPlain (const char *Src, const char *Dest, ppfDirEntry &SrcInfo)

Here's the implementation in Read.cpp:

int     CopyToPlain (const URLInfo &Src, const URLInfo &Dest, ppfDirEntry
&SrcInfo);

That's the reason.

To get the rest of the errors fixed, ppfOpen.cpp needs to be uncommented. It
has some errors, but just add ::pp::internal to all PFile calls it makes.
That done, I get another unresolved external on "int __cdecl
pp::internal::CloseInVirt(struct ppFILE *)". CloseInVirt() isn't declared
anywhere.

> >1 of those being for main() (well, actually
> >_WinMain(), but anyway) )
>
> What error exactly?
>
Well, there IS no main()/WinMain(), so its an unresolved external.

> >Notice that the code I've written positively will not work. The
> reason for
> >this is that I obviously haven't had a chance to test it to find the
> >problems.
>
> Sure. It will need some more debugging iterations until it really *works*.
>
Well, I usually test each part of my code to ensure that it works properly,
so that its relatively bugfree from day 1. I haven't been able to do that
here, since the frame needed to do that isn't there yet.

> >I'm having some problems with interpreting the errorlog you gave
> me. None of
> >your errors turns up on my compiler. Anything that doesn't say
> warning is an
> >error?
>
> Right.
>
Ah, ok. Is there errors and fatal errors on your compiler too? In MS VC++,
an error will not stop compilation, but a fatal error will.

> >If you fix the build errors, this thing might actually just run
> today, or,
>
> Don't expect too much though. I have *very* little time currently.
>
Have you implemented the dos-style paths in URLInfo? Otherwise, I'd like to
have a go at that, mostly because I can't debug anything if that isn't
working...


btw, what do you think of using the standrad library method _stat() instead
of the POSIX-specific stat()? I believe the struct _stat _stat() gives
contains all the information we need (?).